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 / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
