Parse built-in functions

fcollonval commented

2022-07-19 09:34:21 +02:00

(Migrated from github.com)

Would it be acceptable to add built-in functions as parser statements?

I'm gladly push a PR for this.

Would it be acceptable to add [built-in functions](https://docs.python.org/3/library/functions.html) as parser statements? > I'm gladly push a PR for this.

👍 2

marijnh commented

2022-07-19 09:37:53 +02:00

(Migrated from github.com)

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)

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. ```python def plusOne(abs): return abs + 1 plusOne(1) ```

krassowski commented

2023-05-24 21:45:24 +02:00

(Migrated from github.com)

Is there a way for downstream to opt-in or implement these easily? I see the changes in https://github.com/lezer-parser/python/pull/13 go pretty deep into the grammar and patching these would be rather labours. Could it be an opt-in setting?

axil commented

2023-10-06 20:52:38 +02:00

(Migrated from github.com)

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.

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.

👍 14

Atcold commented

2023-11-28 18:39:58 +01:00

(Migrated from github.com)

Coming here from the same perspective of @axil.
How is one supposed to know a given keyword is reserved if it's not highlighted?

Coming here from the same perspective of @axil. How is one supposed to know a given keyword is reserved if it's not highlighted?

👍 4

zzhengnan commented

2024-01-06 05:49:41 +01:00

(Migrated from github.com)

Another potential data point in favor of this request: All major IDEs/editors highlight built-ins, as does command line IPython.

👍 3

Rows
Columns

Parse built-in functions #9