PRE-PEP: new Path class
Mike C. Fletcher
mcfletch at rogers.com
Mon Jan 5 22:05:26 CET 2004
John Roth wrote:
>"Just" <just at xs4all.nl> wrote in message
>news:just-CC8B2B.17325205012004 at news1.news.xs4all.nl...
>>In article <vvivefh35qjv9a at news.supernews.com>,
>> "John Roth" <newsgroups at jhrothjr.com> wrote:
>>>15. Should files and directories be the same
>>>Probably not. While they share a lot of common
>>>functionality (which should be spelled out as an
>>>interface) they also have a lot of dissimilar
>>>functionality. Separating them also makes it easy
>>>to create objects for things like symbolic links.
>>But what about paths for not-yet-existing files of folders? I don't
>>think you should actually _hit_ the file system, if all you're doing is
>I agree here. I haven't looked at any of the candidate implementations
>yet, so I don't know what they're doing. I'm thinking of a
>three class structure: the parent class is just the path manipulations;
>it has two subclasses, one for real files and one for real directories.
>That way they can not only inherit all of the common path manipulation
>stuff, but the developer can instantiate a pure path manipulation
>class as well.
>There might also be a mixin that encapsulates the stuff that's common
>to real files and directories like accessing and changing dates and
>I'm sure there are use cases that will throw a curve at that structure
My implementation combines the two into a single class. Here's the logic:
* There is no necessary distinction between files and directories at
the path level
o Particularly with upcoming ReiserFS 4, where structured
storage shows up, it's possible to have files behaving much
o Zip files also come to mind if we have virtual file system
* These objects represent paths, not the things pointed to by the paths.
o They allow you to operate on the path, which is "almost" the
filesystem, but not quite.
o In the space of "paths", there's no distinction between a
file and a directory, really.
o Even a path that traverses a few symbolic links, and drops
into a zip-file is still just a path, it's a way of
specifying something, similar to a "name" or "location" class.
o You can find out what the path-object points to via the path
methods, but the path itself isn't those objects.
* Don't want to have to explicitly cast your paths to file/directory
to get the basic file/directory operations when joining paths.
o Mix-ins require changing the class of the instance by
somehow figuring out that it's a file, that requires a
file-system access (to what may be a non-existent or very
o There's not much of a conflict between the file/directory
Mike C. Fletcher
Designer, VR Plumber, Coder
More information about the Python-list