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

["Martin v. Löwis"]

Ronald Oussoren schrieb:
>> 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.

By that measure, the entire splitext function is trivial. However,
if you look closely, you find that even such a 'trivial' function
can contain many errors already, and it needs several revisions to
get it right.

This particular function has two errors (as far as I can see):
- if there are multiple leading dots, your version will return
   all of them in ext, even though it's promised that ext will
   contain exactly one dot. IOW, splitext2('...txt') should
   give ('..', '.txt'), but does give ('', '...txt')
- The join() call will insert the module's separator, even
   though the original string may have used the altsep. This
   violates the promise that base+ext == path.

> 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.

That is precisely the core of the discussion. It's not that 
ignore_leading_dots=False is considered useful, in the call (except
for a few people that claim that splitext('.txt') ought to give
'','.txt'), but that the valid use case apparently is to not
pass any parameters, so that 100%, never-changing
backwards-compatibility is preserved.

Regards,
Martin