Guido rethinking removal of cmp from sort method

Steven D'Aprano steve+comp.lang.python at pearwood.info
Thu Mar 31 03:51:09 EDT 2011


On Thu, 31 Mar 2011 01:34:17 -0500, harrismh777 wrote:

>      Many of you (Guido included) have lost significant sight of a
> critical object oriented philosophical pillar (but not all of you, thank
> goodness). To cut right to the heart of it--- NEVER change an advertised
> interface.


Thanks for your comments, M Harris, but I'm afraid you stumble right at 
the first step. The difference between implementation and interface is 
not specific to object-oriented code -- it is no more, or less, an 
"object oriented philosophical pillar" than it is a pillar of functional 
programming, procedural programming, or any other programming paradigm 
(except perhaps spaghetti coding).

Nor should you say "NEVER". To put your advice in other words:

"Once you have added a feature, no matter how badly thought out, broken, 
rarely used, or even actively hated by the entire programming community, 
you must continue supporting it forever, adding more and more cruft 
around it, just in case some obscure piece of software that hasn't been 
maintained for ten years relies on it."

Nobody has forgotten the principle of separating interface from 
implementation. This was not an accidental backwards incompatible 
change, it was a deliberate decision made in the full knowledge that it 
would be a painful move for some, but also in the expectation that *not* 
removing cruft becomes even more painful over time.

Cruft has real costs: maintenance costs, development costs, runtime 
costs, learning costs, and usability costs. Any language which does not 
prune cruft from time to time will ossify and is doing its users a real 
disservice. Just not too often.

Nobody is denying that the loss of list.sort(cmp=...) will hurt some 
people, or some use-cases. The disagreement is over the question of 
whether the pain from its loss outweighs the utility of its removal.

Python is about halfway through the expected migration period from 2.x to 
3.x, and so far it has not been worse or more difficult than expected. 
Support for Python 3 is about what was expected (probably better than 
expected), uptake of Python 3 by users is about what was expected, the 
number of nay-sayers, Negative Nellies and trolls claiming that Python 3 
will destroy the language is about what was expected, and the number of 
credible forks of the language promising to support Python 2 forever is 
exactly what was expected: zero.


[...]
> Many of us dropped JAVA
> (compile once debug everywhere) because it is complicated, a pita to
> use, slow, and actually doesn't port too well on any platform...

Perhaps that's because Java needs to drop some cruft.


> Many of us want to use the new 3.2+ version, but no one is going
> to ship it pre-installed (probably for many years) because of this
> issue.

Wrong. There is at least one Linux distro, Arch, which ships with Python3 
as the system Python. Arch is pretty bleeding edge, but where they go, 
others will follow.

Besides, "pre-installed" loses a lot of importance when installation is 
as easy as "sudo apt-get python3".


> There is no way to easily migrate, nor backport, and everyone is
> going to be forced to develop code (and have to maintain code) on two
> distinct branches (for many years to come).

Your FUD is outdated. There are now many major products which support 
Python 2 and 3, and some of them out of the same code base. Here is a 
small selection:

http://allanmcrae.com/2010/12/python-3-module-support/
http://mail.mems-exchange.org/durusmail/qp/441/
http://nedbatchelder.com/blog/200910/running_the_same_code_on_python_2x_and_3x.html

Note that last link is from 2009.



-- 
Steven



More information about the Python-list mailing list