[Python-Dev] Proposal to revert r54204 (splitext change)
Phillip J. Eby
pje at telecommunity.com
Fri Mar 16 16:13:08 CET 2007
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
> > 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
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.
More information about the Python-Dev