> On 25 Mar 2017, at 02:19, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: > > Terry Reedy wrote: >> PQL expressions should be quoted and passed to the dsl processor, as done >> with SQL and other DSLs. > > But embedding one language as quoted strings inside another > is a horrible way to program. > > I really like the idea of a data manipulation language that > is seamlessly integrated with the host language. > > Unfortunately, PQL does not seem to be that. It appears to > only work on Python data, and their proposed solutions for > hooking it up to databases and the like is to use some > existing DB interfacing method to get the data into Python, > and then use PQL on that.
No, the current solution is temporary because we just don’t have the manpower to implement the full thing: a real system that will rewrite parts of PythonQL queries and ship them to underlying databases. We need a real query optimizer and smart wrappers for this purpose. But we’ll build one of these for demo purposes soon (either a Spark wrapper or a PostgreSQL wrapper). > > I can see little point in that, since as Terry points out, > most of what PQL does can already be done fairly easily > with existing Python facilities. You can solve any problem with basic language facilities. But instead of a simple query expression you will end up with a bunch of for loops (in case of groupby) and numeric indexes into tuples. You can take a look at some of the queries in this use-case and see how they would look in pure Python: https://github.com/pythonql/pythonql/wiki/Event-Log-Querying-and-Process-Mining-with-PythonQL <https://github.com/pythonql/pythonql/wiki/Event-Log-Querying-and-Process-Mining-with-PythonQL> > > To be worth extending the language, PQL queries would need > to be able to operate directly on data in the database, > and that would mean hooking into the semantics somehow so > that PQL expressions are evaluated differently from normal > Python expressions. > > I don't see anything there that mentions any such hooks, > either existing or planned. This is definitely planned, currently PythonQL expressions are evaluated separately because we run them through a pre-processor when you specify the pythonql encoding. We might need to add some hooks like PonyORM does, otherwise we might have to trace iterators to their source thought AST, which can become messy. It is a lot of work, so we’re not promising this in the nearest future. As far as hooks (if the language in integrated into core Python) we will probably have to define some kind of a ‘Datasource’ wrapper function that would wrap database cursors and Spark RDDs, etc. > > -- > Greg > _______________________________________________ > 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/
