Phillip J. Eby schrieb:
> I consider it correct, or at the least, don't think it should be
> changed, as it would make the behavior more difficult to reason about
> and introduce yet another thing to worry about when writing
> cross-version code.
Now it's becoming difficult: several people in favor, some opposed...
I'll wait a bit longer, but will still likely commit it, unless
opposition gets stronger: If the current behavior is incorrect
(in the sense that it contradicts wide-spread intuition), then
an application worrying about this detail should surely make the
2.6 behavior also appear in 2.5 and earlier.
I'm not sure what people actually use splitext for: I guess there
are two applications:
a) given a list of file names, give me all those belonging to a
hard-coded list of extensions (e.g. .py, .pyc, .c, .h). These
won't break, since they likely won't search for "all files
ending in .bash_profile" - there is only one per directory,
and if the want it, they use the entire filename.
b) given a list of file names, classify them for display (the
way the Windows explorer works, and similar file managers).
They use MIME databases and the like, and if they are unix-ish,
they probably reject the current splitext implementation already
as incorrect, and have work-arounds. As these files now show
up with "no extension", I rather expect that the work-around
won't trigger, and the default behavior will be the correct one.
Regards,
Martin
_______________________________________________
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
