PRE-PEP: new Path class

[Christoph Becker-Freyseng]

John Roth wrote:

> I'm adding a thread for comments on Gerrit Holl's pre-pep, which
> can be found here:
> 
> http://tinyurl.com/2578q
> 
> Frankly, I like the idea. It's about time that all of the file
> and directory stuff in the os module got objectified
> properly (or at least with some semblance of OO propriety!)
> 
Great I've been thinking of something like this, while I've been writing 
  a "File-Class" (I'll open a thread for this ...)

[1] I think Path being a subclass of str is odd. There are a lot of 
string-operations that don't fit to path (some of them should be 
implemented in a different way e.g. __mul__ if at all).
However the point with the old os function etc. is very sound. So it 
might be a good idea to have Path being a subclass of str *for 
transition*. But finally all those functions should call str(argument) 
instead of of demanding a str-object as argument (if they don't already 
today).
This determines Path.__str__ to return a valid path-string.
Path's constructor should be able to use such a string.
(when there are Path-Classes for other stuff like URLs we maybe need a 
factory ...)


[21] I think file-paths and directory-paths shouldn't be the same class 
(they have different meaning. Think about a "walk"-function for dirs)
But it might be hard if the path doesn't exist, how to decide whether 
it's a file-path or a dir-path?
You could do the follwing (for Unixes): if its string-representation 
ends with '/' it's a directory otherwise it's a file.
Bash is autocompleting this way but "cd /home" is valid to and would 
cause trouble with this algorithm.
(If the path exists it's easier)

file-path and directory-path should have a common superclass.


There seems to be a distinction between existing and non-existing paths. 
Probably a lot of things shared between file-paths and directory-paths 
are valid for non-existing-paths.


"about a path object that happens to have the ability to do file
system operations in appropriate circumstances" [John Roth]
This is a good thing but I think there are problems: maybe the given 
path does not exist.


This takes me to my last point:
What about invalid paths?
Should Path-Class take care of always being a valid path (this doesn't 
necessarily mean a path of an existing file/directory)
Especially if someone uses string-methods on a Path-object there could 
arise invalid paths, even if finaly the path is valid again.
The validity of filesystem-paths is os/filesystem dependendt.



Christoph Becker-Freyseng