On 2010-07-26, at 16:28 , Guido van Rossum wrote:
On Sun, Jul 25, 2010 at 10:50 PM, Masklinn email@example.com wrote:
On 2010-07-26, at 05:07 , Guido van Rossum wrote:
A lot of code for containers or that uses containers implicitly expects simple invariants to hold: for x in container: assert x in container
Yeah, a lot of code using comparisons also breaks when comparisons don't return bools. It's a specialized use, but I don't see it as anathema.
OTOH the real solution would be something like LINQ in C# (http://msdn.microsoft.com/en-us/netframework/aa904594.aspx, http://en.wikipedia.org/wiki/Language_Integrated_Query).
Most of LINQ itself (the LINQ library, as opposed to the query syntaxes which are solely syntactic sugar and statically compiled into LINQ method calls) can already be implemented in Python.
Well, the point of allowing more general __contains__ overloading is exactly to improve upon the query syntax -- you may call it syntactic sugar (often a derogatory term)
I didn't intend it as such, I just meant that there is nothing the LINQ query syntax allows which isn't available (usually more clearly as far as I'm concerned) via the library part of the same.
but you currently cannot translate an 'in' operator into a parse tree like you can for '<' or '+'.
Why not? How would it be different from + or <? If we have expression trees, then expression recording/recoding can manipulate those and `in` can go back to being (value, collection) -> bool no?
The things that might be missing are *some* LINQ-supporting features. Likely expression trees, maybe (but probably not) less limited and terser lambdas.
That's exactly the point I am driving at here. :-)
Oh well, I probably missed the hints then :(