[Python-Dev] Policy Decisions, Judgment Calls, and Backwards Compatibility (was Re: splitext('.cshrc'))
Phillip J. Eby
pje at telecommunity.com
Fri Mar 9 22:04:08 CET 2007
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:
>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
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.
More information about the Python-Dev