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

[Phillip J. Eby]

At 10:54 PM 3/14/2007 +0100, Martin v. Löwis wrote:
>Phillip J. Eby schrieb:
> > That much is obvious.  But I haven't seen any explanation as to why
> > explicitly-documented and explicitly-tested behavior should be treated
> > as a bug in policy terms, just because people don't like the documented
> > and tested behavior.
>
>It's not "just" that people disliked the behavior. The majority of those
>that commented agreed that the current behavior is incorrect.

And yet, that "incorrect" behavior was clearly intended by the author(s) of 
the code, test, and docstrings.

As it happens, Guido wrote that code (16 years ago) and the docstring (9 
years ago), in the case of the posixpath module at least.

And in an amusing twist, it appears that you yourself checked in the test, 
4 years ago!  If this behavior was so *obviously* buggy, why didn't you ask 
Guido or "fix" it then?

But wait, it gets better!  Five years ago, you also recommended *rejection* 
of a similar patch:

"""I also dislike this patch. The current behaviour completely
matches the documented behaviour; changing it might break
existing applications. If you need a different behaviour,
write a different function."""

http://python.org/sf/536120

So, why is it obviously broken now, but not five years ago?


> > So far, the only policy justification I've seen you give was along the
> > lines of, "I volunteered to do it, so I get to decide".
>
>It's more than that. I conducted a poll, and here people were largely
>in favor of that change. Had they been largely in opposition, I would
>have rejected the patch.

By this logic, I could conduct a popularity poll for say, "fixing" the 
distutils by changing its behavior to match that of setuptools, and go 
ahead with it if the majority agreed with me that the distutils' behavior 
was clearly incorrect by retroactive comparison -- despite it being 
documented and tested behavior, and despite objections of backward 
incompatibility being presented on Python-Dev.

So, I don't understand your reasoning here at all.


>However, *some* action is necessary. The patch was sitting there for
>a long time already, and it is unfair to the submitter to not act just
>because you cannot decide. The bug report was even older.

So reject it, or propose to add a new API.


>P.S. If you apply the same effort to all changes that are constantly
>being made to Python, you will find that you will need to revert many
>of them.

Then I'm amazed that there is so much desire to *increase* the number of 
changes being made to Python, if we can't even manage to follow our 
policies *now*.