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

Phillip J. Eby pje at telecommunity.com
Mon Mar 19 17:28:44 CET 2007

At 12:53 PM 3/18/2007 -0700, Guido van Rossum wrote:

This is an experiment for me as well; if you all would prefer me to stay out of it, I will.

With respect to the specific change, it seems to me that there is an emerging consensus for adding keyword arguments to support the new behaviors, so I'm not sure a pronouncement is needed. As far as I'm aware, the main question left open is whether the default behavior should change in a future version of Python, and if so, which version.

To be concrete, I think that if Phillip had written a different kind of post instead of the one where he requests the reversal of the submit (only parenthetically mentioning Martin) then perhaps Martin wouldn't have felt the need to dig in and defend his position, and the issue might have been resolved quicker and at less emotional expense.

Martin's position was already abundantly clear; the fact that he had checked in the change despite prior opposition demonstrated that a personal appeal was already moot -- the "digging in" had already taken place a week or two prior, when the use cases were first presented and objections were first raised, and Martin simply dropped the discussion and checked it in anyway. He left my last message in that discussion (laying out a detailed rationale for rejecting the change) without a reply:

http://mail.python.org/pipermail/python-dev/2007-March/071798.html

So I was absolutely stunned when I found the change had been checked in, anyway.

To be concrete, if Martin had spent less time trying to discredit and discard the use cases of the people being "polled" about the question, a compromise could perhaps have been reached before he applied the patch, and the second discussion would never have needed to happen.

In other words, the second discussion was the result of Martin "digging in" and ignoring objections, not the cause of it.

I'm trying to stay out of the feature discussion, but I would like to point out that a policy that, in the sake of some strict definition of backwards compatibility, forces us to introduce new APIs (or new optional parameters to existing ones, which is really the same thing) at a high rate is also doomed to have an overall detrimental effect on the language -- who know, perhaps more so than the occasional incompatible change.

I don't advocate a mechanically-enforced policy, either. But it seems to me that when a behavior is documented and has valid use cases, changing the behavior to benefit people who didn't pay any attention to the documentation or test their code for corner cases is punishing the vigilant to aid the ignorant, and that seems unwise for us as a community. Likewise, attempting to retroactively fix latent bugs for one group at the cost of introducing latent bugs for another group doesn't seem like a net improvement.

More information about the Python-Dev mailing list