Guido rethinking removal of cmp from sort method

Paul Rubin no.email at nospam.invalid
Fri Apr 1 22:29:59 EDT 2011


Steven D'Aprano <steve+comp.lang.python at pearwood.info> writes:
> What I'm saying is this: cmp is already removed from sorting, and we 
> can't change the past. Regardless of whether this was a mistake or
> not, 

No it's not already removed, I just tried it (in Python 2.6, which is
called "Python" for short) and it still works.  It's not "removed" from
Python until basically all Python users have migrated and "Python"
essentially always means "Python 3".  Until that happens, for Python 2
users, Python 3 is just a fork of Python with some stuff added and some
stuff broken, that might get its act together someday.  I see in the
subject of this thread, "Guido rethinking removal of cmp from sort
method" which gives hope that one particular bit of breakage might get
fixed.

> the fact is that it is gone, and therefore re-adding it is a new feature 
> request. Those who want cmp functionality in Python 3 have three broad 
> choices: ...
> (3) port the feature that they want into a third-party module, ...
> I'm suggesting that #3 is a more practical, useful approach ...
> Having to do:
>    from sorting import csort ...
> If fans of functional programming can live 
> with "from functools import reduce", fans of cmp can live with that.

If "sorting" is in the stdlib like functools is, then the similarity
makes sense and the suggestion isn't so bad.  But you're proposing a 3rd
party module, which is not the same thing at all.  "Batteries included"
actually means something, namely that you don't have to write your
critical applications using a library base written with a Wikipedia-like
development model where anybody can ship anything, where you're expected
to examine every module yourself before you can trust it.  Stuff in the
stdlib occasionally has bugs or gaps, but it has a generally consistent
quality level, is documented, and has been reviewed and reasonably
sanity checked by a central development group that knows what it's
doing.  Stuff in 3rd party libraries has none of the above.  There are
too many places for it to go wrong and I've generally found it best to
stick with stdlib modules instead of occasionally superior modules that
have the disadvantage of coming from a third party.



More information about the Python-list mailing list