I like it! The obvious question, though: How would "*from package import keyword*" be handled, if not simply by SyntaxError? Would *from package import keyword as keyword_* be allowed?
In a similar vein, what would happen with stdlib functions like operator.not_? The thought of writing "operator.not" is appealing, but being forced to use *that* (with *from operator import not* being non-allowable) may not be. On Sun, May 13, 2018, 11:20 AM Guido van Rossum <gu...@python.org> 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. > > I should also mention that this was inspired from some messages where Tim > Peters berated the fashion of using "reserved words", waxing nostalgically > about the old days of Fortran (sorry, FORTRAN), which doesn't (didn't?) > have reserved words at all (nor significant whitespace, apart from the > "start in column 7" rule). > > Anyway, just throwing this out. Please tear it apart! > > -- > --Guido van Rossum (python.org/~guido) > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
