[Python-ideas] Small enhancement to os.path.splitext

Tarek Ziadé ziade.tarek at gmail.com
Tue Apr 20 18:47:50 CEST 2010


On Tue, Apr 20, 2010 at 6:25 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 20 April 2010 17:10, Tarek Ziadé <ziade.tarek at gmail.com> wrote:
>> Or maybe simply drop that idea and just use path.endswith(extension)... :)
>>
>> In that case the only subtle case is when the filename starts with '.',
>>
>> So what about a new API :
>>
>>   os.path.hasext(path, extensions)
>>
>> That would return True if the path match on extension provided in the
>> extensions sequence
>> (using .endswith, but ignoring the first dot if the filename starts with a dot)
>
> That should take into account filesystem case sensitivity if it's to
> meet user expectations. Which is a whole can of worms that you
> probably don't want to open - certainly not for the standard library
> without expecting a lot of work!
>
> The current stdlib functions - all of which simply split up the
> filename - avoid the problem, leaving it to the application to address
> case sensitivity issues.
>
> (Of course, if you want to start down this route, I'd suggest you
> start with a function which, given a directory name, determines if
> that directory's treats file names within it as case sensitive or not.
> I'm not even sure if this is possible to implement in any sane way,
> but it would be the key building block for any other path matching
> code, such as your os.path.hasext proposal).

I am not sure to follow the issue. Do you mean that in the same filesystem,
each directory can treat case sensivity differently ? I wasn't aware of that.

How would this affect the extension btw ?   I can imagine that
the path+extensions could to be normalized before the matching job, but
I don't see other issue, do you have an example ?


>
> Paul.
>



-- 
Tarek Ziadé | http://ziade.org



More information about the Python-ideas mailing list