[Python-Dev] Proposal to revert r54204 (splitext change)

[Stephen J. Turnbull]

Paul Moore writes:

 > On 16/03/07, Phillip J. Eby <pje at telecommunity.com> wrote:
 > > What's *actually* under dispute here is whether it's acceptable to classify
 > > this perfectly useful-as-is behavior, that was documented and tested in
 > > released versions of Python for several years (with patches to change its
 > > behavior explicitly rejected in the past), as a "bug".
 > 
 > Just to put this into context, the word "bug" is probably not the
 > best to use here. The orignal behaviour was described as a bug,
 > certainly, but that's not how the change has been treated. [...]
 > Rather, the change is being treated as a behaviour change (which it
 > is) and submitted for a *feature* release (2.6).

Very well put, and the main point.

 > Whether the behaviour change is good, reasonable, acceptable -
 > that's the question here.  (And one on which I don't have an
 > opinion!)

That definition of the question is open-minded of you.  However,
Phillip's point remains valid.  Eg, Martin's clear preference for not
changing API and mild resistance to a warning suggests that the design
of this change is strongly influenced by the feeling that current
behavior is a "bug".  I think that's inappropriate.  Note that Phillip
(and glyph, AIUI) is not opposing a behavior change in Python; he
simply wants the current API to keep the same spec (here I mean the
docstring).

I have seen many discussions like this one on various Emacs-related
lists, and I would not use a mild phrase like "the word 'bug' is
probably not the best to use here".  In my experience, use of the word
"bug" to describe behavior that is consistent with all documented
specifications is usually a political play.  When such a change is
described as a feature, the majority of programmers who haven't
careful studied the spec will say "I thought it already does that now,
and I wish it would."  When it is described as a bugfix, that changes
to "I thought it already does that now, so I demand that it do so."
(All this is much less true of Python, but the dynamic can be seen
here, too.)

That is, even in a feature release backward compatibility is very
important, it's just not paramount any more.  If you describe it as a
new feature, then people are very likely to accept the admittedly
expensive process of defining a new API for the improved behavior, and
where necessary deprecating the old behavior, and finally removing it.
If you describe it as a bugfix, many will not.

My opinion is that this shift of atmosphere leads to bad decisions.
In cases where behavior conforms to spec, the process of define new
API -- deprecate -- remove, though expensive, is almost always a good
investment.  It both lowers compatibility costs, and makes them much
more plan-able.  These costs are both large and easy to underestimate,
so that's a very good thing.