[Python-ideas] Non-boolean return from __contains__

Bruce Frederiksen dangyogi at gmail.com
Wed Jul 28 02:17:44 CEST 2010


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 at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100727/f51726e9/attachment.html>


More information about the Python-ideas mailing list