Josiah Carlson wrote:
> Talin <[EMAIL PROTECTED]> wrote:
>
>>Ian Bicking <ianb <at> colorstudy.com> writes:
>>
>>>Josiah Carlson wrote:
>>>
>>>>One of the features of generator expressions which makes it desireable
>>>>instead of list comprehensions is that generator expressions may use
>>>>less memory *now*, and may be able to start returning results *now*.
>>>>
>>>>Using (<genexp> orderby ...) as a replacement for sorted((genexp), key=...)
>>>>is a bit misleading because while the original generator expression
>>>>could have been space and time efficient, the orderby version certainly may
>>>>not be.
>>>
>>>Certainly it changes the performance substantially (of course if the
>>>expression is translated and executed elsewhere the performance can
>>>actually be improved, so it can go both ways). Since list
>>>comprehensions are planned to just be syntactic sugar for generator
>>>comprehension, generator comprehensions are now the more fundamental
>>>construct.
>>>
>>>But yeah, it is a little awkward, since something that is sorted can be
>>>returned as a list anyway, except for the fact that the expression
>>>itself could be ported off elsewhere which isn't normal Python. (But
>>>should be normal Python!)
>>>
>>
>>I think that I am (mostly) in agreement with Ian on this one, but perhaps with
>>different reasoning.
>>
>>There seems to be a common feeling on py-dev that "list comprehensions are
>>just
>>a special case of generators expressions, so really, we don't need them".
>>
>>But then we turn around and say "Well, this feature might be handy for list
>>comprehensions, but since list comprehensions are based on generator
>>expressions, and since this feature would make generator expressions
>>inefficient, we won't do it."
>
>
> No. I was only responding to the question of orderby in relation to
> generator expressions. In generator expressions, it is further
> unnecessary because one can always wrap the generator expression up with
> a sorted(genexp, ...) to get your sorted version of the generator (in
> list form).
>
> In the case of list comprehensions, it is doubly unnecessary, because
> you can again use sorted([genexp], ...) or even list.sort(...) .
Using sorted is syntactically different:
[(p.fname, p.lname) for p in person
orderby (p.lname, p.fname)]
vs:
sorted((p.fname, p.lname) for p in person,
key=lambda name: (name[1], name[0]))
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.
>>The fact is that sorting happens a *lot*. Sorting with key= happens a lot. A
>>large proportion of my list comprehensions involve sorting or ordering of one
>>form or another, and the number of ugly sorted + key + lambda expressions is
>>enough to convince me that an "orderby" or "ascending" or whatever clause
>>would
>>be a welcome addition.
>
>
> Sorting may happen "a *lot*" with what you write, but in the software
> that I write, sorting *rarely* happens. If you would like to lessen
> your use of lambda, you should consider discovering the
> operator.attrgetter() and operator.itemgetter() functions to be passed
> to sorted().
Well now you are just being silly...
foo.sort(key=lambda x: x.name)
or
import operator
foo.sort(key=operator.attrgetter('name'))
? 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().
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
