Guido rethinking removal of cmp from sort method

Paul Rubin no.email at nospam.invalid
Fri Apr 1 17:37:20 EDT 2011


Terry Reedy <tjreedy at udel.edu> writes:
>> IWhatever2 setting the new parameters to default values
> Now you have two versions, and eventually many more, to maintain and
> document. 

In the case of cmp= there's not two interfaces needed.  Python2 does a
perfectly good job supporting cmp and key with one interface.  We do
have urllib and urllib2 as separate interfaces (with separate
implementations), and we keep some other legacy interfaces around too,
like the sha and md5 modules (both of which are now subsumed by
hashlib).

> That takes resources we currently do not have.

Well ok, but now you're making excuses for instability, which seems like
a problem given Python's self-marketing as a stable, production-class
system that competes with better-funded efforts like Java.

> Example: Python2 added str2 (= unicode) on top of str. This had all
> the problems listed above. Since CPython uses str internally, in
> particular for identifiers, CPython users were stuck with the
> limitations of str. Rebinding str to mean str2 has many benefits,
> especially in the future, in addition to current costs.

That really is a massive change, but a welcome one, because Python2
programs broke all the time due to missed conversions between str and
unicode.  It is the type of thing that a language transition (Python2 to
Python3) is supposed to bring, that goes beyond Interface2 to
Interface3.  There's been a lot of experience gained in the decades
since Python's creation and it's fine to do an overhaul after all these
years.  The issues are 1) don't break stuff unless there's a substantial
benefit; and 2) don't do these major incompatible releases too often.
There should not be any incompatible Python4 before 2020 or so.

I actually think Python3 actually didn't go far enough in fixing
Python2.  I'd have frankly preferred delaying it by a few years, to
allow PyPy to come to maturity and serve as the new main Python
implementation, and have that drive the language change decisions.
Instead we're going to have to give up a lot of possible improvements we
could have gotten from the new implementation.



More information about the Python-list mailing list