"Martin v. Löwis" wrote:
> It's not "just" that people disliked the behavior. The majority of
> those
> that commented agreed that the current behavior is incorrect. Some
> also
> observed that the online documentation was underspecified, and indeed
> allowed for that change. So this is a bug fix, even though the old
> test
> case explicitly tested for the presence of the bug, and even though
> the
> doc string explicitly documented the old behavior. They were all
> consistent, but they were consistently wrong.
The patch special-cases one edge case where an "extension" does not indicate
the type of the file, but metadata on a particular platform.
Here's a couple of other edge cases that are not addressed by the patch:
On Mac OS (including Mac OS X) you can have a file without an extension, where
the type is specified in the metadata. However, such a file could also happen
to contain a dot in the file name:
splitext("Version 1.2") -> ("Version 1", "2")
Also, quite often you have multiple extensions:
splitext("file.tar.gz") -> ("file.tar", "gz")
To me, the "extension" there is "tar.gz".
Basically, changing the behaviour of splitext() is simply trying to make it "do
what I mean" (DWIM). But it's never going to DWIM. I think the best we can do
is have a simple, unambiguous rule, with no exceptions - which is what the
existing behaviour does.
Tim Delaney
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
