Hi Terry!

Thanks for your feedback, I have a couple comments below.

> On 24 Mar 2017, at 20:50, Terry Reedy <tjre...@udel.edu> wrote:
> 
> On 3/24/2017 11:10 AM, Pavel Velikhov wrote:
>> Hi folks!
>> 
>>  We started a project to extend Python with a full-blown query language
>> about a year ago. The project is call PythonQL, the links are given
>> below in the references section. We have implemented what is kind of an
>> alpha version now, and gained some experience and insights about why and
>> where this is really useful. So I’d like to share those with you and
>> gather some opinions whether you think we should try to include these
>> extensions in the Python core.
> 
> No. PythonQL defines a comprehension-inspired SQL-like domain-specific 
> (specialized) language.  Its style of packing programs into expressions is 
> contrary to that of Python.  It appears to me that most of the added features 
> duplicate ones already in Python (sorted, itertools, named tuples?).  I think 
> it should remain a separate project with its own development group and 
> schedule.

These features do exist separately, but usually they are quite a bit less 
powerful and convenient, then the ones we propose, and can’t be put into a 
single
query/expressions. For example namedtuple requires one to define it first, the 
groupby in itertools doesn’t create named tuples and sorted takes a single
expression.

I do agree that synching releases with the overall Python code can become a 
problem...

> 
> This is not to say that I would never use PQL.  I like he idea of a uniform 
> method of accessing in-memory and on-disk date, and like Python's current 
> method of making files an iterable of lines.  I believe the current DB API 
> allows something similar.
> 
> I think that the misuse of coding cookies, which makes it unusable in code 
> that already has a proper coding cookie, should be replaced by normal 
> imports.  PQL expressions should be quoted and passed to the dsl processor, 
> as done with SQL and other DSLs.

So we see a lot of value of having PythonQL as a syntax extension, instead of 
having to define string queries and then executing them.
It would definitely make our lives much simpler if we go with strings. But a 
lot of developers use ORMs just to avoid having to construct
query string and have them break with a syntax error in different cases.

In our case I guess we can avoid a lot of the hassle associated with query 
strings, since we can access all variables and functions from the context
of the query. But when you’re doing interactive stuff in rapid development mode 
(e.g. doing some data science with Jupyter notebook) language
integrated queries could be quite convenient.

This is something we’ll need to think about...

> 
> -- 
> 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/

_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to