[Python-Dev] splitext('.cshrc')
Scott David Daniels
Scott.Daniels at Acm.Org
Thu Mar 8 15:28:50 CET 2007
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
Scott.Daniels at Acm.Org
More information about the Python-Dev
mailing list