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

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:


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

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