Guido rethinking removal of cmp from sort method
Steven D'Aprano
steve+comp.lang.python at pearwood.info
Sat Apr 2 06:13:36 EDT 2011
On Fri, 01 Apr 2011 15:37:34 -0400, Terry Reedy wrote:
> On 4/1/2011 3:45 AM, Paul Rubin wrote:
>
>> What happens then is you define a new interface. In Microsoft-speak if
>> the IWhatever interface needs an incompatible extension like new
>> parameters, they introduce IWhatever2 which supports the new
>> parameters. They change the implementation of IWhatever so it becomes a
>> wrapper for IWhatever2 setting the new parameters to default values, to
>> keep implementing the old behavior.
This is exactly the sort of cruft I am talking about. Languages can
survive a small amount of cruft, but eventually they bloat to the point
that the only thing keeping them going is inertia. They become dinosaurs,
like COBOL or PL\I, or bloated monstrosities like .Net, Java or C++ that
nobody *likes* but merely keep using because they have to.
No offense to anyone who actually likes .Net, C++ or Java *wink*
If we follow this "rule" (more of a guideline really) of no interface
changes ever, eventually we will be up to Python 5.2 and IWhatever12.
This imposes serious maintenance costs, documentation costs, learning
costs for new users, and even decision costs when you write a function:
"Should I use the list, list2, sortable_list, sortable_list2,
sortable_lost3, [note spelling, which we're stuck with forever],
heterogeneous_list, heterogeneous_list_without_stooge_sort, new_list,
fancy_list, fancy_list2, fancy_list_with_extra_oomph, newer_than_new_list
or list3?"
Each and every interface carries a cost. Even if it is small, that cost
must be weighed up against the benefits, rather than declaring that all
interfaces are sacred once published.
Removing a published interface imposes a one-time cost on those using
that interface, but it has an on-going benefit for all.
> Now you have two versions, and eventually many more, to maintain and
> document. That takes resources we currently do not have.
Exactly. The "no interface changes ever" rule assumes that the human
resources dedicated to maintenance are unlimited, that the cost of
keeping multiple interfaces around is zero, and that the cost of removing
an interface is infinite.
None of those assumptions are even *remotely* true in the real world.
(If the cost of removal were assumed to be merely large, or even huge,
then there could be circumstances where the benefit outweighed the cost,
and the rule would be "*Almost* never change a published interface".)
To be sure, interface stability is a good thing. But it is not the only
good thing, and it is not so good that it always outweighs every other
consideration.
--
Steven
More information about the Python-list
mailing list