On 3/26/2017 7:14 AM, Pavel Velikhov wrote:
On 26 Mar 2017, at 07:23, Terry Reedy
Someone mentioned the problem of adding multiple new keywords. Even 1
requires a proposal to meet a high bar; I think we average less than 1
new keyword per release in the last 20 years.
Searching '\bgroup\b' just in /lib (the 3.6 stdlib on Windows) gets
over 300 code hits in about 30 files. I think this makes in
ineligible to bere's match.group() accounts for many. 'select' has
fair number of code uses also. I also see 'where', 'let', and 'by' in
the above.
Yes, we add quite a few keywords. If you look at the window clause we
have, there are even more keywords there.
This is definitely a huge concern and the main reason that the community
would oppose the change in my view.
I’m not too experienced with Python parser, but could we make all these
keywords not be real keywords (only interpreted
inside comprehension as keywords, not breaking any other code)?
It might be possible (or not!) to make the clause-heading words like
'where' or 'groupby' (this would have to be one word) recognized as
special only in the context of starting a new comprehension clause. The
precedents for 'keyword in context' are 'as', 'async', and 'await'. But
these were temporary and a nuisance (both to code and for syntax
highlighting) and I would not be in favor of repeating for this case.
For direct integration with Python, I think you should work on and
promote a more generic approach as Nick has suggested. Or work on a 3rd
party environment that is not constrained by core python. Or you could
consider making use of IDLE; it would be trivial to run code extracted
from a text widget through a preprocessor before submitting it to compile().
--
Terry Jan Reedy
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
