key argument for max?

[Alex Martelli]

Raymond Hettinger <python at rcn.com> wrote:
   ...
> > Unfortunately, no.  I think that the excellent key= optional argument to
> > sort should be extended to every order-related Python tidbit; min and
> > max are examples, but so should the heapq module's functions.
   ...
> It should definitely be pursued for Py2.5.   I'm the one who shot it
> down the first time it came up and now wish that it had gotten a full
> hearing.

Yeah, I remember well.

> The issue was political.  Getting a key= argument for sort() was a big
> win; however, proposing to propagate the idea could have jeopardized
> everything by arousing the ire of the gathering anti-change movement.

You and I disagreed very intensely about it at the time, as you'll
recall.  I'm not sure if you now really _do_ wish it had gotten a full
hearing, as you said in the first paragraph, or still think it was a
politically preferable move to avoid it, as you appear to imply here.
No matter, I guess, what's past is past.  I'm sure you realize the way
you moved to prevent that hearing was the main reason I stepped away
from python-dev afterwards.


> P.S.  The heapq module's new nsmallest() and nlargest() functions are
> suitable for the key= argument; however, the other functions are not.

Incidentally, those two functions are as good in usefulness as they are
badly misplaced in location.  If one wants the "three smallest items",
the issue of what algorithm is used to get them should not be primary.
Unfortunately, I can't suggest a better location in today's stdlib.
Maybe that's an argument for AMK's idea that redoing the library should
be focus #1 of 2.5.  The idea that useful functionality either doesn't
get in, or sneaks into some odd corner, does suggest that the library's
overall organization isn't all it could be.

> Unfortunately, the heap is not a collection object in its own right. 
> I don't see a way to attach an ordering function or a reversed=
> argument for the whole heap.  Such arguments would have to be passed
> on every call to heapify(), heappop(), heappush(), and heapreplace().

That one's easier to fix -- we can make a collections.heap type (module
collections feels so threadbare now, with just deque in it!-).


Alex