[Python-Dev] Policy Decisions, Judgment Calls, and Backwards Compatibility (was Re: splitext('.cshrc'))

[Phillip J. Eby]

At 07:18 PM 3/9/2007 +0100, Martin v. Löwis wrote:
>Phillip J. Eby schrieb:
> > At 08:57 AM 3/9/2007 +0100, Martin v. Löwis wrote:
> >> In the case that triggered the discussion, the change implemented
> >> was not an incompatible change, because the new implementation still
> >> met the old specification (which, of course, was underspecified).
> >
> > No, it wasn't, actually.  Read the doc strings, which state exactly what
> > the code does.
>
>The doc strings were precise, yes. The documentation (Doc/lib) was
>underspecified and allowed for both interpretations:
>
>splitext(path)
>Split the pathname path into a pair (root, ext) such that root + ext ==
>path, and ext is empty or begins with a period and contains at most one
>period.

I'm just pointing out that anyone who reads *all* the documentation would 
reasonably conclude that the more specific of the two pieces is a reliable 
description of the behavior.

Therefore, this is a change to documented behavior, and can't be considered 
a bug fix.

I agree 100% with the people who think splitext() should arguably have had 
the new proposed behavior from the beginning.

However, I also agree 100% with Glyph that it's ridiculous that we should 
even have to be having this argument about changing something that's been 
like this for about a *decade* and can reasonably be considered to not be a 
bug, given that its detailed behavior is clearly documented in the 
docstrings.  Where were all these "10 Unix programmers" for the last ten years?

Obviously they've been writing their own replacement for splitext(), if and 
when they needed one -- or else the normal use cases for splitext either 
aren't dotfile-sensitive, or are *conducive to the existing 
implementation*.  In other words, one of four cases apply for existing code:

1. Old code uses its own fucntion - change has no effect

2. Old code uses splitext, but never has and never will touch dotfiles - 
change has no effect

3. Old code uses splitext, and has never touched dotfiles (otherwise it 
would have been changed to not use splitext!) but *might*, *possibly*, 
touch one at some point in the future - change *might* fix a latent bug in 
such code, but clearly it's unlikely

4. Old code uses splitext, does touch dotfiles, *likes it that way* - 
change breaks code.  (A small, but definitely non-empty group.)

So, ignoring the cases where the change makes no difference, this change will:

1. DEFINITELY break some code
2. MAYBE "fix" some code that hasn't actually broken before

I don't see how a hypothetical fix for one small group justifies definitely 
breaking the code of some other small group.

The only group the change benefits is people writing *new* code -- so give 
them a new function.