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

Stephen J. Turnbull stephen at xemacs.org
Fri Mar 16 20:59:51 CET 2007

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.

More information about the Python-Dev mailing list