For the LINQ approach, I'd rather see an open ended hook for allowing any required syntax, rather than only SQL-like syntax.

OTOH, re.compile and db_cursor.execute are two examples where no new mechanism is needed. And you'd have to quote the new syntax somehow anyway since the Python parser wouldn't understand it...

Which makes me wonder if it really makes sense to try to overload these operators in order to generate some kind of mini-language, vs just using your own syntax like re.compile or db_cursor.execute does.

The one catch is that it is often nice to be able to refer to Python variables (at least; or perhaps full expressions) within the mini-language. The db_cursor.execute is an example, and putting the placeholders in the SQL syntax with arguments later works, but gets tedious. To be able to include Python expressions directly within the mini-language, the library implementing the new syntax would have to be able to translate the new syntax into Python and have it spliced into the code where it was used. Something like an intelligent macro expansion. This means that the library's translation code has to be called from the Python compiler.

I'm not familiar enough with the compiler to know how crazy this is. Mython tries to do something similar.

-Bruce

On Tue, Jul 27, 2010 at 10:02 AM, Guido van Rossum <guido@python.org> wrote:

Therefore I think the LINQ approach, which (IIUC) converts an
expression into a parse tree when certain syntax is encountered, and
calls a built-in method with that parse tree, would be a fresh breath
of air. No need deriding it just because Microsoft came up with it
first.