[Python-ideas] Crazy idea: allow keywords as names in certain positions
brenbarn at brenbarn.net
Sun May 13 14:49:11 EDT 2018
On 2018-05-13 11: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).
> Of course this would still not help for names of functions that might be
> imported directly (do people write 'from numpy import where'?). And it
> would probably cause certain typos be harder to diagnose.
People definitely do write "from numpy import where". You can see
examples just by googling for that string. And that's only finding the
cases where "where" is the first thing in the from clause; there are
probably many more where it's something like "from numpy import array,
sin, cos, where".
I think this kind of special casing would be really confusing though.
It would mean that these two would work (and do the same thing):
from np import array
And this would work:
But then this would fail:
from np import where
That would be really puzzling. Plus, we'd still have the problem of
backwards compatibility. Before the new "where" keyword was introduced,
the last example WOULD work, but then afterwards you'd have to change it
to look like the third example. This might induce wary programmers to
hide all names behind a period (that is, find a way to do "foo.bar"
instead of just "bar" whenever possible) in order to guard against
future keywordization of those names.
The other thing is that I suspect use of such a privilege would explode
due to the attractiveness of the reserved words. That is, many
libraries would start defining things named "and", "or", "with", "is",
"in", etc., because the names are so nice and short and are useful in so
many situations. So there'd be nowhere to hide from the deluge of names
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
More information about the Python-ideas