[Python-3000] Adding sorting to generator comprehension

Thu Apr 27 00:19:41 CEST 2006

Ian Bicking <ianb at colorstudy.com> wrote:
> Josiah Carlson wrote:
> > 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.

That is quite a circuitous route to get some LINQ syntax into Python. 
Personally, I've never been terribly enamoured with SQL-like syntaxes,
so the idea of orderby (when we can always post-process) isn't terribly
appealing to me.
> 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).

I guess I haven't seen any of these hackish techniques.
> >>? 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.

I would also argue that not using Python's already built-in
metaprogramming features to solve this particular problem is also
disingenous. More specicifically...
class Getters:
 def __getattr__(self, attr):
 return operator.attrgetter(attr)
 def __getitem__(self, item):
 return operator.itemgetter(item)
G = Getters()
class tpl:
 def __init__(self, *items):
 self.items = items
 def __call__(self, item):
 if len(self.items) == 1:
 return self.items[0](item)
 return tuple(i(item) for i in self.items)
x = sorted(((i.firstname, i.lastname) for i in names),
 key=tpl(G.lastname, G.firstname))
Now that I've gone ahead and both made operator.*getter() more
equivalent from a syntax standpoint, as well as made multi-key sorting
more convenient I'm hard-pressed to find any benefit to orderby instead
of sorted, except for perhaps a speed improvement due to the reduction
in function calls, and as a first step towards a LINQ-ish syntax.
Now that we've gotten that out of the way, do we want LINQ-ish syntax
for Python? As I said earlier in this email, I never much liked SQL
syntax, and LINQ seems to be a variant of SQL embedded in certain parts
of other languages, so I would answer: no, I don't want LINQ-ish syntax
for Python.
 - Josiah