Python still wins hands down on this example both in verbosity and readability: But AFAICS, the Python version you give creates a temporary. One of the advantages cited for LINQs functional programming paradigm is that it specifies what is wanted at a higher level, so the compiler can decide whether to create temporaries, and can also decide whether to farm the thing off to multiple processors

I haven't yet had occasion to use LINQ in anger yet, so I have no idea whether its an idea to love or to hate. I do think it is good that C# has effectively sprouted list comprehensions (not to mention anonymous types and type inferencing) and I expect there may be some aspects worth looking at for Python but I think they are more likely to lead to itertools functions than extensions to syntax. Yes, looking at what LINQ adds to C# (according to http://msdn.microsoft.com/en-gb/library/bb397909.aspx): - Implicitly typed variables: Python already has. - _object_ and collection initialisers: Not sure whether Python can do this directly, but it can certainly emulate it with a dictionary. - Anonymous types: Not sure whether Python can do this directly, but it can certainly emulate it with a dictionary. - Extension methods: Python already has. - Lambda _expression_s: Python already has. - Auto-Implemented properties: No, but that's just syntactic sugar to make declarations more compact. So all of the language elements that are needed for LINQ are already in Python; a library should do the trick. Not quite. The C# implementation of lambda _expression_s has a neat trick that is central to LINQ. A lambda _expression_ compiles either to executable code, or to an _expression_ tree. If you are filtering some C# sequence _object_ then (as with Python lambdas) the LINQ code simply calls the compiled lambda _expression_ like any other delegate, but if you are filtering a SQL lookup the LINQ code gets an _expression_ syntax tree and further compiles it (at runtime) into SQL code to perform the filtering at the data_base_ level. Python can't do the compile time matching to vary what it produces according to how the lambda is used, but it would be perfectly possible for function _object_s which are compiled from a lambda _expression_ to grow an extra attribute that would hold an AST for the _expression_. That way you could write code that took a filter function and, if it had the AST attribute available, compiled it to SQL or xpath or whatever else you fancied.