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

Phillip J. Eby pje at telecommunity.com
Wed Mar 14 23:30:53 CET 2007

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.

More information about the Python-Dev mailing list