[Python-ideas] Crazy idea: allow keywords as names in certain positions
carl.input at gmail.com
Sun May 13 23:04:06 EDT 2018
As long as any new syntax allowed us to still reference the occassional
thing in the older libraries that used newly reserved names, it would
not come up that often, and would avoid the biggest cost of a whole
If `foo` was a reserved word, then this could be allowed...
import foo as bar
...but not these...
import bar as foo
The same could be done with params, so this would be illegal...
def f(foo): ...
...but this would be fine...
It would be illegal to define a property named `foo`, but you could
still do `bar.foo` to use a library, etc.
It could be done, but it's not especially relevant here, so I'll shut up
-- Carl Smith
carl.input at gmail.com
On 14 May 2018 at 03:47, Rob Cliffe via Python-ideas <
python-ideas at python.org> wrote:
> On 13/05/2018 19:19, Guido van Rossum wrote:
> As anyone still following the inline assignment discussion knows, a
> problem with designing new syntax is that it's hard to introduce new
> keywords into the language, since all the nice words seem to be used as
> method names in popular packages. (E.g. we can't use 'where' because
> there's numpy.where
> and we can't use 'given' because it's used in Hypothesis
> The idea I had (not for the first time :-) is that in many syntactic
> positions we could just treat keywords as names, and that would free up
> these keywords.
> For example, we could allow keywords after 'def' and after a period, and
> then the following would become legal:
> class C:
> def and(self, other):
> return ...
> a = C()
> b = C()
> This does not create syntactic ambiguities because after 'def' and after a
> period the grammar *always* requires a NAME.
> There are other positions where we could perhaps allow this, e.g. in a
> decorator, immediately after '@' (the only keyword that's *syntactically*
> legal here is 'not', though I'm not sure it would ever be useful).
> Please, imagine how you would write the documentation to explain this.
> Then, please, put yourself in the position of someone who teaches Python
> trying to explain it.
> Rob Cliffe
> Python-ideas mailing list
> Python-ideas at python.org
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas