Chris Angelico wrote:
I've been a C++ programmer for nearly twenty years. I think I know a few things about OOP. Actually, I've done OOP in non-OO languages; most notably, plain old C. The OS/2 Presentation Manager class hierarchy (SOM) is primarily implemented in C, for instance. My point is that "object orientation" is completely separate from "implementation is separate from interface".
Thank you for helping me there with your stats...
Not sure where Knowledge (OOP) comes in there. Must ask my DM some day.
Ok, its an honest question. The answer is the heart of this debate, actually. Please be patient and try to hear this... the bickering on this thread about whether the cmp= removal is a bad thing has been focused on the *wrong issue*. The issue is not whether there is a use-case. The issue is not whether there is a technical reason for justifying the existence of L.sort(cmp= ). The issues debated ad nauseum here by most folks are missing the real point (the main issue).
The real issue facing the community in this cmp= debate is whether an established, documented, useful, widely *used* advertised class interface should be removed (don't miss this) for strictly philosophical reasons based on the expectations of the OOP client community in terms of trust and accountability (OOA&D) for the established promises of the advertised class interfaces of an *advertised* OOP scripting language--- er, Python.
In other words, does the PSF have a responsibility to maintain the L.sort(cmp= key= reverse=) interface for strictly *philosophical* principle based on established norms for *any* OOP language? (and) is there OOA&D expectation for this principle?
The rest of the thread is arguing for a *technical* determination for inclusion of the cmp= keyword... I am arguing (on the other hand) for a *philosophical* determination for inclusion of the cmp= keyword.
But this is getting seriously off-topic; none of this connects with the cmp= parameter.
Well, we have to agree to disagree on that point... my view is that this is right-on-topic. Guido should restore the interface, period. And the main point is that this is regardless of technical underpinnings like "cruft," performance issues, &etc.
Now, there may be other issues... CPython to PyPy, for instance, that may or may not affect this ... I don't know. That's not my problem. My problem is that the class list(object).sort(cmp= key= reverse=) interface will be broken in 3.3+ unless somebody argues well for inclusion. Some folks are arguing for inclusion based on technical merit... and that's fine... I am arguing based on philosophical premise and OOA&D OOP expectations from the OOP Python client community.
Please forgive me, if I made you feel insulted,... that was not intended. Kind regards, m harris -- http://mail.python.org/mailman/listinfo/python-list
