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

[Sjoerd Mullender]

On 03/16/2007 05:43 PM, Nick Coghlan wrote:
-- 
Sjoerd Mullender
> Phillip J. Eby wrote:
>> At 01:31 PM 3/16/2007 +0100, Martin v. Löwis wrote:
>>> Phillip J. Eby schrieb:
>>>> 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.
>>
> 
> That may actually be a genuinely useful approach:
> 
> splitext(name, ignore_leading_dot=False, all_ext=False)
> 
>    Split the extension from a pathname. Returns "(root, ext)".
>    By default, the extension is all characters from the last dot to the

Presumably that would be the last dot after the last separator (i.e. /
and/or \).  I would not expect ext to ever contain a separator.

> end of the string. "ext" will be empty if there are no dots in the name
> and "root" will be empty if the characters starts with a single dot and
> that is the only dot in the name.
>    If ignore_leading_dot=True, then a leading dot is always considered
> part of "root", and is ignored when determining the extension. "root"
> will never be empty in this case.
>    If all_ext=True, the extension is all characters from the first dot to
> the end.
> 
>> 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.
> 
> Not sure what can be done about that... although such filenames are 
> likely a big reason why grabbing 'all extensions' will typically be a 
> bad idea.
> 
> Regards,
> Nick.
> 


-- 
Sjoerd Mullender