[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