[Xah Lee] > This part i don't particular agree: > > > * The reason for implementing the key= parameter had nothing to do > > with limitations of Python's compiler. Instead, it was inspired by > > the > > decorate-sort-undecorate pattern. > > The decorate-sort-undecorate pattern is a compiler limitation, for > most of today's langs. I'm not sure, but i think some of the fancy > functional langs automatically detect such and optimize it away, to > various degrees. > > ... my criticism is usually written in a style catered to irritate a > particular class of coder i call tech geekers (they think of themselfs > with their idiotic term “hackers”). So, parts are exaggerated. It'd be > more clear to say, that the reason for python's “key”, and as a > “solution” or need of the decorate-sort-undecorate issue, can be > attributed to the current state of the art of popular imperative > language's compilers (induced by such lang's semantics).
I'm not following you here. If you're saying that it is possible for a compiler to automatically transform a cmp argument into a key argument, transforming O(n log n) calls into O(n) calls, then I don't see how that could be done (a cmp argument can be a C function that is not introspectable or an arbitrarily complex python function that may be difficult to analyze and transform programmatically). The key function was introduced as a simpler way for programmers to write the commonly used decorate-sort-undecorate pattern -- compiler limitations had nothing to do with it. In general, key functions are not a terribly new or inflexible concept. The SORT BY clauses in SQL are an example. That being said, it is a fair criticism of Python's compiler that it does not do much in the way of optimizations. It does a handful of basic peephole optimizations but that is about it. Other languages like Haskell fair better in this regard. Raymond -- http://mail.python.org/mailman/listinfo/python-list
