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

[Ronald Oussoren]

On 20 Mar, 2007, at 15:54, Phillip J. Eby wrote:

> At 09:24 AM 3/20/2007 +0100, Ronald Oussoren wrote:
>> I don't agree. "all_ext=True" is won't do the right thing in a
>> significant subset of filenames
>
> Yes, that's understood.  The problem is that splitext() in general  
> "won't do the right thing", for many definitions of "the right  
> thing", unless you're applying it to a fairly constrained range of  
> filenames, or unless you add other code.  This won't change, unless  
> we get rid of splitext() altogether.

I know that, I actually read most of the messages in this thread. The  
reason I'm pointing this out for the 'all_ext=True' case is that  
adding this flag could give naive users even more reason to believe  
that splitext will magicly do the right thing.

>
> If you're trying to match an archive extension, for example, you'll  
> probably need to loop on repeated splitext() calls until you find  
> an extension that matches.  One benefit of using both the new  
> keyword arguments together is that it allows you to make your loop  
> proceed from longest match to shortest, so that if you are matching  
> product-X.Y.Z.tar.gz, you're going to go through  
> matching .Y.Z.tar.gz, then .Z.tar.gz, then .tar.gz.

I don't know if this is worth the additional API complexity.  
Especially given the inherit problems of a splitext function.

>
>
>> The ignore_leading_dot argument also doesn't buy you anything that  
>> can't
>> trivially be implemented in other ways.
>
> I don't understand.  Example?

You conveniently ignored my other arguments ;-).

Given a splitext that ignores leading dot's the following function  
doesn't:
       # from os.path import *
       def splitext2(path):
             dn = dirname(path)
             bn, ext = splitext(basename(path))
             if bn.startswith('.') and ext == '':
                 return dn, bn + ext
             else:
                return join(dn, bn), ext

I'd say that's a trivial function.

What I don't understand is why 'ignore_leading_dot==False' is  
considered to be a valid usecase at all, except for the fact that  
os.path.splitext did this until py2.5. I'm definitely in the camp  
that considers '.profile' not to have an extension.

Ronald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3562 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20070320/fb99f4a7/attachment-0001.bin