On Sun, Mar 10, 2019 at 6:07 AM Jonathan Fine <jfine2...@gmail.com> wrote: > He then correctly says that in my proposal the lack of whitespace > after an operator can cause the operator to absorb a following > identifier. > > However, something similar ALREADY happens in Python. > >>> a = nota = True > >>> not a > False > >>> nota > True > > Today, whenever a Python operator ends in a letter, and is followed by > an identifier, white space is or some other delimiter is required > between the two. Python, rightly, refuse to guess that 'notary' might > be 'not ary'. > > Here is another example > >>> e = note = None > >>> e is not e > False > >>> e is note > True > > This is not quite what's happening with '@b'. With 'is not e' the > following identifier 'e' absorbs the 'not' from the operator to create > 'note'.
Python's grammar is defined in terms of tokens. There is a specific token 'not' which can be used in three ways: either 'not' followed by a valid expression, or as part of the operators 'not in' and 'is not', both of which are then followed (and preceded) by expressions. If the parser sees 'note', it doesn't see the token 'not'; it sees a NAME token. That's not the case with '@'. There is no way that '@foo' could be a single NAME token, because an at sign cannot be part of a NAME. There is a VAST difference, both to humans and to the parser, between "note" and "@e", and the fact that "not e" is different from "note" does not mean that "@e" can be different from "@ e". As Anders says, pick something that's not currently valid syntax and then you won't be up against this problem. ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
