[Python-ideas] Proposal: Query language extension to Python (PythonQL)
Terry Reedy
tjreedy at udel.edu
Sun Mar 26 21:26:40 EDT 2017
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
More information about the Python-ideas
mailing list