-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parse built-in functions #9
Comments
These can be shadowed, since they are just identifiers in the grammar, so I don't think it is a good idea to treat them specially. def plusOne(abs):
return abs + 1
plusOne(1) |
Is there a way for downstream to opt-in or implement these easily? I see the changes in #13 go pretty deep into the grammar and patching these would be rather labours. Could it be an opt-in setting? |
Here, syntax highlighting serves as a hint that this is a keyword and it should not be shadowed. Without highlighting, it is much easier to shadow it for a newbie. I teach python to students at a university who happen to be 'fluent' in other programming languages, and it is a common error for them to name variables as 'list', 'str', 'sum', 'min/max', 'id' or 'vars', which are not built-ins in other languages. Of course they will learn it — later — but bad habits are simpler to form than they are to break. There is no easy way for them to see if these names are built-ins or not unless they are highlighted. I would strongly vote for keeping them highlighted. |
Coming here from the same perspective of @axil. |
Another potential data point in favor of this request: All major IDEs/editors highlight built-ins, as does command line IPython. |
Would it be acceptable to add built-in functions as parser statements?
The text was updated successfully, but these errors were encountered: