[Python-3000] Adding sorting to generator comprehension

Wed Apr 26 22:24:14 CEST 2006

Josiah Carlson wrote:
>>It's not a huge difference, but to argue that it's unnecessary because 
>>sorted() exists is the same as arguing that list/generator 
>>comprehensions are unnecessary because of map/imap and filter/ifilter.
>>> You can draw parallels as to why my argument vis-a-vis sorted doesn't
> work, and I will point out my original argument; orderby takes O(nlogn)
> time and O(n) space (given a generator that would have returned n items).
> Fundamentally, one of the reasons to use generator expressions rather
> than list comprehensions was that you wouldn't have to wait for all of
> the items, and not all items would need to be in memory simultaneously. 
> This would be a not-insignificant change in time/memory use *semantics*.
>> The use of orderby in generator expressions is fundamentally equivalent
> to the Decorate-Sort-Undecorate pattern on lists. While I believe that
> such would be convenient, I also believe that it is inherantly dishonest
> from a time/space expectation perspective to allow them in generator
> expressions. In list comprehensions? Sure. At least one isn't being
> quite so dishonest from a time/space perspective, but then one is
> getting the equivalent of an automatic syntax conversion from...
>> [... orderby XXX]
>> to...
>> sorted((...), key=lambda x: XXX)
>> Is this desireable? As I said above, yes. Is it a compelling syntax
> addition? I don't believe so. Do Ian and Talin believe it compelling?
> It would seem so. The question remains whether others also find it a
> compelling (or not) addition to the list comprehension or generator
> expression syntax, vis-a-vis the change in memory and time use of
> orderby in generator expressions.

My ulterior motive for introducing this into generator expressions is 
that then generator expressions could be used to do LINQ-ish things. 
This isn't required for that, but it pulls the entire idea together 
better than a generator expression plus a lambda. List comprehensions, 
being immediately evaluated, cannot be used in this fashion.
This is admittedly a rather roundabout reason for orderby, but it's also 
a relatively nonintrusive way to introducing a feature for which there 
is demonstrable demand (since people are already doing this in Python in 
using even more hackish techniques).
Ignoring this ulterior motive, I also think it's a nice feature for list 
comprehension.
>>Well now you are just being silly...
>>> Indeed, but only if you use operator.attrgetter and operator.itemgetter
> as their full names. One can always bind those functions to other names
> in any namespace.
>>>>>? That second one is just there for people who are irrationally opposed 
>>to lambda, it's not a serious alternative. If someone asked me how to 
>>sort based on an attribute, I would *never* tell them to use 
>>operator.attrgetter().
>>> Interesting, I didn't realize that any portion of the standard library
> was influenced due to 'irrational opposition to lambda'. I could have
> sworn the opposite (given lambda's use in so many of the standard
> library modules).

Offering operator.attrgetter as an alternative to a simple lambda is 
either a disingenous argument (because the person so arguing is very 
unlikely to actually make that choice in their own code, or seriously 
suggest it to other people), or is based on a desire to use a highly 
functional style that borders on the irrational. There are some reasons 
you would use attrgetter, though not many; there's no good reason to use 
that function with a string literal argument.
-- 
Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org