Guido rethinking removal of cmp from sort method

[harrismh777]

Terry Reedy wrote:
>> When I speak of implementation vs interface I am speaking from a
>> strictly object oriented philosophy, as pedigree, from Grady Booch, whom
>> I consider to be the father of Object Oriented Analysis and Design
>> (Booch, OO A&D with apps, 1994).

>
> Python is object based but not object oriented in the Booch sense.
>
> . . . and Python is not OOA&D based.

     With due respects Terry, these statements you have made are 
categorically not true. Even a casual perusal of the Python supplied 
documentation and helps (documented class interfaces) make it very clear 
that OOP and OOA&D are at the very heart of the design of Python.
     To help clear this up a bit, and keeping in line with the cmp 
notion of this thread, I have posted (at the very end of this entry) a 
portion of the class definition for list(object) from several releases, 
each of which resides on at least one of my production servers:
     2.3
     2.4.1
     2.5.2
     2.6.2
     2.7.1
     3.2
I have snipped out the center section of the class definition but have 
left the heading and the sort() method for comparison. I am going to try 
to be making several points with these examples as follows:
     1)  cmp is integral to advertised class interface since (2005).
     2)  OOP and OOA&D are integral to Python definition, period.
     3)  semantics aside, removing cmp breaks the spirit of OOA&D
First, all of the primary books tout (even sport) Python as object 
oriented (not just object based). This is important to note; just a 
couple of examples:

     "[Python] is commonly defined as an object-oriented scripting 
language--a definition that blends support for OOP with an overall 
orientation toward scripting roles" (Lutz, Learning Python, 4th ed, 2009).

     "We use the term base class to refer to a class that is inherited; 
a base class may be the immediate ancestor, or may be further up the 
inheritance tree" (Summerfield, Programming in Python 3: A complete 
Introduction to the Python Language, 2nd ed, 2010).

     It cannot be denied that we are talking exclusively about OOP. End 
of story. Granted, Python certainly does not implement the Booch OOA&D 
like SmallTalk does, nor Eiffel, nor C++. Regardless, it is very clear 
that the OOA&D concepts from Booch are present consciously or 
unconsciously in most of what Python is doing.

     To really get a good feel for this all one has to do is use the 
help() method from the Python interpreter command prompt and then enter 
  list  at the help prompt.  I have attached at the end of this item the 
   class list(object)  definitions for several Python versions showing 
the defined  Methods  :--- specifically the sort().

     First it will be clearly seen that we are looking at an OOP OOA&D 
class definition with internal and external attributes and methods, 
defined as a class with function methods, including sort(). To say that 
Python is not based in OOA&D is to make an asinine statement. Very 
obviously OOA&D was at the lovely heart of the Python design. Obviously 
Booch didn't get credit for it..., but his methodology is very clearly 
present.
     Second it can be clearly seen that beginning in 2.3 there was 
needed a comparison function. In the Programming Python book 3rd ed the 
comparison worked with the class definition like this:

     L.sort( lambda x, y,: cmp(x['n'], y['n']) )

          (Lutz, Programming Python, 3rd ed, 2006)

In 2.4 cmpfunc= was replaced with (cmp= key= reverse=) which remains 
with the definition through 2.7.1 today. It is clear that the cmp= 
keyword is not in any way "cruft," nor is it in any way obscure. It was 
needed, wanted, useful, desired, and most importantly implemented and 
advertised. End of the sad sad story.

     The Python clients (yes, I'm one of those) must be able to make 
assumptions about the class definitions of an advertised object-oriented 
language. Otherwise, the excellent OOA&D work that obviously went into 
the   class list(object).sort()   is pointless.  If the clients using 
sort() cannot rely on the advertised class interface for their projects 
into the future then their use of the language is weakened, and maybe in 
the end not as useful.

      Python is obviously OOP with the concepts of OOA&D at the heart of 
the project's design. Denying this truth in order to justify breaking 
the spirit of OOA&D is not only not helpful, it adds insult to injury.

     But this is worse, because programmers are not the only ones who 
rely on the advertised interface. When the interface is in flux the only 
people who benefit short term are the language designers. The clients 
who might otherwise benefit long term may never see that day because 
they are forced to remain on a previous release far into the future. 
(@Steven ---this is not FUD... No Fear, Absolutely Certain, No Doubt) 
But the other folks who lose on this type of nobbled thinking are the 
ones who write the books, and the tutorials, and the ones who teach the 
students... and of course students.

     Take a look at these obviously OOP OOA&D designs showing the 
evolution and stability of L.sort(cmp= key= reverse=)... and try to see 
this "removal" from the eyes of the clients who are forced to clean up 
your mess:

------------------------       python2.3

class list in module __builtin__:

class list(object)
  |  list() -> new list
  |  list(sequence) -> new list initialized from sequence's items
  |
  |  Methods defined here:
  |
  |  sort(...)
  |      L.sort(cmpfunc=None) -- stable sort *IN PLACE*; cmpfunc(x, y) 
-> -1, 0, 1
  |

------------------------       python2.4.1

class list in module __builtin__:

class list(object)
  |  list() -> new list
  |  list(sequence) -> new list initialized from sequence's items
  |
  |  Methods defined here:
  |
  |
  |  sort(...)
  |      L.sort(cmp=None, key=None, reverse=False) -- stable sort *IN 
PLACE*;
  |      cmp(x, y) -> -1, 0, 1
  |

------------------------       python2.5.2

class list in module __builtin__:

class list(object)
  |  list() -> new list
  |  list(sequence) -> new list initialized from sequence's items
  |
  |  Methods defined here:
  |
  |
  |  sort(...)
  |      L.sort(cmp=None, key=None, reverse=False) -- stable sort *IN 
PLACE*;
  |      cmp(x, y) -> -1, 0, 1
  |

------------------------       python2.6.2

class list in module __builtin__:

class list(object)
  |  list() -> new list
  |  list(sequence) -> new list initialized from sequence's items
  |
  |  Methods defined here:
  |
  |  sort(...)
  |      L.sort(cmp=None, key=None, reverse=False) -- stable sort *IN 
PLACE*;
  |      cmp(x, y) -> -1, 0, 1
  |

------------------------       python2.7.1

class list in module __builtin__:

class list(object)
  |  list() -> new empty list
  |  list(iterable) -> new list initialized from iterable's items
  |
  |  Methods defined here:
  |
  |  sort(...)
  |      L.sort(cmp=None, key=None, reverse=False) -- stable sort *IN 
PLACE*;
  |      cmp(x, y) -> -1, 0, 1
  |

------------------------       python3.2

class list in module builtins:

class list(object)
  |  list() -> new empty list
  |  list(iterable) -> new list initialized from iterable's items
  |
  |  Methods defined here:
  |
  |  sort(...)
  |      L.sort(key=None, reverse=False) -- stable sort *IN PLACE*
  |

------------------------       python3.x.?