[Python-3000] Adding sorting to generator comprehension

[Josiah Carlson]

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