Filename type (Was: Re: finding file size)

[Peter Otten]

> [Peter Otten]
>> >>I think both filename class and os.path functions can peacefully
>> >>coexist.
> 
> [Gerrit Holl (me)]
>> >Thanks for the links.
>> >(I think they don't, by the way)
> 
> [Mike C. Fletcher]
>> Is that peaceful?  I don't know.  If there's a war, let's be honest,
>> os.path is going to take a good long while to defeat because it's there
>> and embedded directly into thousands upon thousands of scripts and

[Gerrit Holl]
> Sure, I don't think os.path would die soon, it will surely take longer
> than the string module to die. But I think there is a number of places
> where Python could be more object-oriented than it is, and this is one
> of them. The first step in making those modules more object-oriented is
> providing a OO-alternative: the second step is deprecating the old way,
> and the third step is providing only the OO-way. The third step will
> surely not be made until Python 3.0.

I don't think OO is a goal in itself. In addition to the os.path functions'
ubiquity there are practical differences between a path and the general str
class.

While a string is the default that you read from files and GUI widgets, a
filename will never be. So expect to replace e. g.

os.path.exists(somestring) 

with 

os.filename(somestring).exists()

which is slightly less compelling than somefile.exists().

Are unicode filenames something we should care about?
Should filename really be a subclass of str? I think somepath[-1] could
return the name as well.
Should files and directories really be of the same class?

These to me all seem real questions and at that point I'm not sure whether a
filename class that looks like a light wrapper around os.path (even if you
expect os.path to be implemented in terms of filename later) is the best
possible answer.

Peter