Social problems of Python doc [was Re: Python docs disappointing]

[Raymond Hettinger]

[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