H
harrismh777
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.?
