[Python-Dev] Proposal to revert r54204 (splitext change)
"Martin v. Löwis"
martin at v.loewis.de
Tue Mar 20 17:07:41 CET 2007
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
> 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.
More information about the Python-Dev