Guido rethinking removal of cmp from sort method

[Terry Reedy]

On 4/1/2011 2:44 AM, harrismh777 wrote:
> Terry Reedy wrote:
>> Python 3 was announced and as a mildly code breaking version at least 5
>> years before it came out.
>
> I appreciate the spirit of your arguments overall, and I do not
> necessarily disagree with much of what you are saying. I would like to
> challenge you to see this from a little different perspective, if I may.

I have, but I consider your perspective, as I understand it, unrealistic

> There are two distinct ways for looking at this "mild code breakage,"
> and it might be good to think about how we approach changes in the
> future based on an understanding of both perspectives, and consideration
> for the clients.

Guido especially and the other developers, generally, try to balance 
benefit and cost. What some may not know is that we consider benefits 
over several years, and benefits to future users as well as current 
users. We hope and expect the former to outnumber the latter in not too 
many years.

The decision, about the time of 2.2, to put off most non-bugfix 
code-breaking changes until 3.0, rather than spread them over the 
remainder of 2.x, was in large part based on the expressed wishes of at 
least some users. (I myself would have preferred sooner and more spread 
out.)

> In the possible perspective of the Python language developers 3x changes
> are mild

Compared to the changes to both the language and implementation Guido 
once considered, they are! But the Perl 6 fiasco and an article by Joel 
Spolsky advocating evolutionary, not revolutionary, software change 
prompted him toward mininal change that would meet objectives. Many 
proposed changes were rejected.

> The perspective of the Class client is something quite different.

There is no 'Class' in Python. Module and function clients have the same 
perspective. Python classes are just instances of class 'type'. Modules, 
instances of class 'module', are sometimes regarded as singleton 
classes. Functions are instances of various classes. Methods are 
functions until bound as instances of bound-method classes. Functions 
are sometimes an alternative to classes, one favored by those of a more 
functional rather than strictly OOP bent.

In any case, you seem to include the interface of class attributes (such 
as the list.sort function) as part of the class interface. Since 
anything can be a class attribute, freezing 'class interfaces' freezes 
everything.

> When you get ready to change an advertised Class interface in the
> future, please consider my interface rules

Taken strictly, they pretty much prohibit anything but implementation 
changes. If we allow the addition of numbered versions of modules, 
classes, and functions, with nothing ever deleted, then we would have 
massive bloat, with attendant maintenance and documentation problems. 
Some modules might be up to v20 by now. Certainly, the switch from ascii 
to unicode as the default text encoding (and I am not sure your rules 
would allow that) changed the interface of nearly every module and a 
large fraction of classes.

Let me reiterate that PSF and Python are not Microsoft and Office. 
Resources are primarily voluntary and limited, but code and even 
binaries are available indefinitely, so no one is forced by *us* to 
switch any particular Python program to any other version of the language.

If you think your rules are workable, try developing a fork that obeys 
them.... but wait, maybe there already is one: 2.7, which will only get 
bugfixes and invisible implementation changes for several years. Of 
course, implementation changes must be screened carefully because in the 
real world, as opposed to the imagined Booch world, it is all to0 easy 
to accidentally introduce an interface change for some corner case.

Also, an implementation change that exchanges space for time will be 
seen an an interface change by somebody. Do you include space-time 
behavior in *your* definition of interface (that should not be changed)?

Indeed, some object to the removal of cmp precisely on this basis, not 
on the fairly trivial code rewrite it entails. This was the case with 
the Google example that prompted this thread. The Googler may well have 
written fresh code, as code breakage was *not* the issue. If the 
list.sort change had been purely an implementation change, if cmp 
remained but its had been changed to use cmp_to_key internally, there 
would have been many of the same objections expressed on this thread anyway.

So why is there a problem with cmp? Because there are people who want 
most of the changes that break your rules, but not this particular one.

-- 
Terry Jan Reedy