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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
