PRE-PEP: new Path class

[Mike C. Fletcher]

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
>>>class.
>>>
>>>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
>>path.join().
>>    
>>
>
>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
>permissions.
>
>I'm sure there are use cases that will throw a curve at that structure
>as well.
>  
>
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
            like directories.
          o Zip files also come to mind if we have virtual file system
            support eventually
    * 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
            expensive-to-access file).
          o There's not much of a conflict between the file/directory
            path operations

Enjoy,
Mike

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/