Martin v. Löwis wrote: > 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. c) Given a filename, make an appropriately named associated file. pyo_name = os.path.splitext(name)[0] + '.pyo' This argues for os.path.splitext('.pythonrc') == ('.pythonrc','')
-- -- Scott David Daniels [EMAIL PROTECTED] _______________________________________________ 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