[Python-ideas] Crazy idea: allow keywords as names in certain positions

[Brendan Barnwell]

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
> <https://docs.scipy.org/doc/numpy-1.14.0/reference/generated/numpy.where.html>,
> and we can't use 'given' because it's used in Hypothesis
> <http://hypothesis.readthedocs.io/en/latest/quickstart.html>.)
>
> 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()
> print(a.and(b))
>
> 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.

	Spooky!  :-)

	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):

import np
np.array(...)

from np import array
array(...)

	And this would work:

import np
np.where(...)

	But then this would fail:

from np import where
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 
shadowing keywords.

-- 
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is no 
path, and leave a trail."
    --author unknown