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

[Phillip J. Eby]

At 01:31 PM 3/16/2007 +0100, Martin v. Löwis wrote:
>Phillip J. Eby schrieb:
> > Some other options:
> >
> > 1. Deprecate splitext() and remove it in 3.0
>
>How would that help the problem? Isn't it useful to have a function
>that strips off the extension?

Not if there's no consensus as to what "extension" means.  Proposals to add 
sorted dictionaries or routines to add "non-duplicate" items to a list or 
to "flatten" data structures are routinely rejected for the same reason: 
users are recommended to write a routine that does what their particular 
application needs.


> > 2. Add an optional flag argument to enable the new behavior
>
>How would that help backwards compatibility?

All existing calls to splitext() would work the same way they've done for 
several years, and the documentation would now make it obvious to new users 
of the function that there's a choice about how to handle dotfiles.  Heck, 
we could throw in another optional argument to strip multiple extensions 
like .tar.gz.

For that matter, the documentation should address the issue that no matter 
what options you use, you may *still* end up with unexpected results, for 
files like "Release 1.2", due to the fuzzy nature of the concept of a file 
"extension" on modern OSes.


> > 3. Create a new function with the new behavior (as you proposed the last
> > time there was a patch submitted for this)
>
>What to do with the old function in this case?

Leave it alone - it's not broken.  If people have buggy programs because 
they assumed '.foo' files were handled in a way that the docstrings and 
tests clearly indicate they are *not*, and they didn't test their *own* 
program, it's not Python's responsibility to fix their programs.