This definitely reminds me of LINQ (never having used it).
As much as I dislike things like this that translate a language into another, but not quite right, as you have one syntax trying to mimic a completely different one, you do (or could) get the benefit of the possibility of autocompletion, syntax highlighting and lint checks.
I know that adding something like LINQ in Python is completely out of the question, as you'd have a special syntax case, and I agree with that.
For some time I've wondered how hard would it be to reverse traverse the Python AST to find literal strings that are being passed to a dbapi2 interface, and syntax highlight/lint/autocomplete the SQL on those strings. This gets there by bypassing the "Language is in a string" issue.
You're pretty lucky that you haven't had to know SQL to have good luck.
Having used Linq2SQL for a few years, I don't like this style of coding. Often, to optimize a query, we've had to look at the generated SQL and then reverse engineer it back to Linq to get the SQL that we wanted. While certain queries were really easy in Linq2SQL, the more complex ones were extremely difficult. I had to still understand and write the underlying SQL, then I had to figure out how to "translate" that into the Linq2SQL. In the long run, all time savings were nullified. I see the same with a DSL-type of wrapper like this.
Additionally, almost all good backend devs speak SQL, I can take a Java-person and without the Linq2SQL stuff, he could understand our backend, work on queries, etc. The Linq just added another layer of complexity for someone to think about.
(Granted, there's a database layer that we could truly put a lot of that stuff in, if our queries got really complex)
I haven't used linq2SQL or anything, just LINQ on collections in .NET.
A team I'm a part of (language is C#) had to get rid of a library that handled SQL and do the SQL manually because the library was making a lot of inefficient calls. Sounds like a similar problem.
As much as I dislike things like this that translate a language into another, but not quite right, as you have one syntax trying to mimic a completely different one, you do (or could) get the benefit of the possibility of autocompletion, syntax highlighting and lint checks.
I know that adding something like LINQ in Python is completely out of the question, as you'd have a special syntax case, and I agree with that.
For some time I've wondered how hard would it be to reverse traverse the Python AST to find literal strings that are being passed to a dbapi2 interface, and syntax highlight/lint/autocomplete the SQL on those strings. This gets there by bypassing the "Language is in a string" issue.