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
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
