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

Python-Dev mailing list

Reply via email to