[Python-Dev] Alternative path suggestion

[Nick Coghlan]

Greg Ewing wrote:
> Nick Coghlan wrote:
> 
>> So I suggest splitting the internal data into 'path elements separated 
>> by os.sep', 'name elements separated by os.extsep'
> 
> What bothers me about that is that in many systems
> there isn't any formal notion of an "extension",
> just a convention used by some applications.
> 
> Just because I have a "." in my filename doesn't
> necessarily mean I intend what follows to be
> treated as an extension.

This is an interesting point - I've been tinkering with this a bit (despite my 
best intentions about not getting distracted by the topic ;), and it's 
starting to look like treating directory paths and file paths identically 
poses significant problems for an object-oriented API.

For example, appending a filename or a relative directory path to an existing 
directory path is fine (giving a filename or directory path as the result), 
but you can't do either to a filename.

Listing the entries or walking a file doesn't make any sense either.

And extension information is typically significant only for filenames, not for 
directories.

When paths are just strings, the distinction doesn't matter because the 
instances have no inherent behaviour - it is the application that carries the 
state regarding whether something is meant to be a directory name or a file name.

So it makes a lot more sense to have separate Dirpath and Filepath (and 
possibly Linkpath) objects - from an OO point of view, the methods provided 
for each of these kinds of filesystem entities will be significantly 
different. A common parent Path object may still make sense if there's 
sufficient overlap, though (e.g. retrieving status related information).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org