> > On 25 March 2017 at 11:24, Pavel Velikhov <pavel.velikhov at gmail.com> > wrote: > > 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). > One thought, if you're lacking in manpower now, then proposing > inclusion into core Python means that the core dev team will be taking > on an additional chunk of code that is already under-resourced. That > rings alarm bells for me - how would you imagine the work needed to > merge PythonQL into the core Python grammar would be resourced? > I should say that in practice, I think that the solution is relatively > niche, and overlaps quite significantly with existing Python features, > so I don't really see a compelling case for inclusion. The parallel > with C# and LINQ is interesting here - LINQ is a pretty cool > technology, but I don't see it in widespread use in general-purpose C# > projects (disclaimer: I don't get to see much C# code, so my
experience is limited). I see lots of C# code, but (thankfully) not so much LINQ to SQL. Yes, it is a cool technology. But I sometimes have a problem with the SQL it generates. Since I'm also a SQL developer, I'm sensitive to how queries are constructed, for performance reasons, as well as how they look, for readability and aesthetic reasons. LINQ queries can generate poorly-performing SQL, since LINQ is a basically a translator, but not an AI. As far as appearances go, LINQ queries can look pretty gnarly, especially if they include sub queries or a few joins. That makes it hard for the SQL dev (me!) to read and understand if there are performance problems (which there often are, in my experience) So, I would tend to code the SQL separately and put it in a SQL view, function or stored procedure. I can still parse the results with LINQ (not LINQ to SQL), which is fine. For similar reasons, I'm not a huge fan of ORMs either. Probably my bias towards designing the database first and building up queries to meet the business goals before writing a line of Python, C#, or the language de jour. -- Gerald Britton, MCSE-DP, MVP LinkedIn Profile: http://ca.linkedin.com/in/geraldbritton
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
