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

[M.-A. Lemburg]

On 2007-03-15 07:45, Martin v. Löwis wrote:
> Phillip J. Eby schrieb:
>> And yet, that "incorrect" behavior was clearly intended by the author(s) 
>> of the code, test, and docstrings.
>>
>> As it happens, Guido wrote that code (16 years ago) and the docstring (9 
>> years ago), in the case of the posixpath module at least.
> 
> I don't find it that clear that it was the intention, AFAICT, it could 
> have been an accident also. Guido added the doc strings as a 
> contribution from Charles G. Waldman; he may just have documented the
> implemented behavior.
> 
> In r4493, Sjoerd Mullender changed splitext (in an incompatible way)
> so that it would split off only the last extension, before, foo.tar.gz
> would be split into 'foo', '.tar.gz'. So it's clear that the intention
> was always to "split off the extension", whether or not the behavior
> on dotfiles was considered I cannot tell.
> 
> As for Doc/lib, in r6524 Guido changed it to document the actual 
> behavior, from
> 
> the last component of \var{root} contains no periods,
> and \var{ext} is empty or begins with a period.
> 
> to
> 
> and \var{ext} is empty or begins with a period and contains
> at most one period.
> 
> So it seems the original (Guido's) intention was that it splits
> of all extensions; Sjoerd then changed it to split off only the
> last extension.

Whatever the intention was or has been: the term "extension"
itself is not well-defined, so there's no obvious right way
to implement an API that splits off an extension.

E.g. in some cases, .tar.gz is considered an extension, in others,
the .gz part is just a transfer encoding and .tar the extension.
Then you have .tgz which is a bit of both. It also depends on the
platform, e.g. on Windows, only the very last part of a filename
is used as extension by the OS to determine the (MIME) type of
a file.

As always, it's best to just right your own application-specific
code to get defined behavior.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Mar 15 2007)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::