Python's simplicity philosophy

[Andrew Dalke]

Alex:
> >Given that the sort method of lists now has an optional key= argument, I

Bengt Richter
> This is a new one on me:
>  >>> seq.sort(key=lambda x:x)
>  Traceback (most recent call last):
>    File "<stdin>", line 1, in ?
>  TypeError: sort() takes no keyword arguments
> Do you mean the comparison function? Or is there something else now too?

Quoting from Brett Cannon's most excellent
  python-dev Summary for 2003-10-01 through 2003-10-15

 =============================================
Decorate-sort-undecorate eye for the list.sort guy
--------------------------------------------------
Raymond Hettinger suggested adding built-in support for the
decorate-sort-undecorate (DSU) sorting idiom to list.sort (see the
Python Cookbook recipe at
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52234 which is
recipe 2.3 in the dead tree version or Tim Peters' intro to chapter 2
for details on the idiom).  After a long discussion on the technical
merits of various ways to do this, list.sort gained the keyword
arguments 'key' and 'reverse'.

'key' takes in a function that accepts one argument and returns what the
item should be sorted based on.  So running ``[(0,0), (0,2),
(0,1)].sort(key=lambda x: x[1])`` will sort the list based on the second
item in each tuple.  Technically the sort algorithm just runs the item
it is currently looking at through the function and then handles the
sorting.  This avoids having to actually allocate another list.  If
'key' and 'cmp' are both provided then 'key' is called on the items to
be sorted and the function's return values are then passed to 'cmp'.

'reverse' does what it sounds like based on whether its argument is true
or false.

list.sort also became guaranteed to be stable (this include 'reverse').

A discussion of whether list.sort should return self came up and was
*very* quickly squashed by Guido.  The idea of having a second method,
though, that did sort and returned a copy of the sorted list is still
being considered.

Contributing threads:
   `decorate-sort-undecorate
<http://mail.python.org/pipermail/python-dev/2003-October/038652.html>`
   `list.sort
<http://mail.python.org/pipermail/python-dev/2003-October/038772.html>`
 =============================================

> I'm beginning to infer that key= is actually a keyword arg for a
_function_
> to get a "key" value from a composite object (in which case ISTM
"getkeyvalue" or "valuefunc"
> would be a better name). But IMO "key" suggests it will be used on
elements x like x[key],
> not passing a definition key=whatever and then using key(x) to get values.

I concur.  (Ooops, should have said "Me too!"  :)


> >That would be max(seq, key=len) in my proposal.
>
> That's a nice option for max (and min, and ??), but ISTM that it would
> also be nice to have a factory for efficient iterators of this kind.
> It would probably be pretty efficient then to write
>
>     maxlen, maxitem = max(funumerate(len,seq))

With generator expressions this is

  maxlen, maxitem = max( ((len(x), x) for x in seq) )

It still has the (slight) problem that it assumes x is comparable
when there are multiple items with the same length.  Nearly
all of these quicky versions make that assumption.  The
quicky will-work-for-any-item version would look more like

  maxlen, pos, maxitem = max( ((len(x), i, x) for i, x in enumerate(seq)) )


                    Andrew
                    dalke at dalkescientific.com