PRE-PEP: new Path class
webmaster at beyond-thoughts.com
Thu Jan 8 00:11:05 CET 2004
Gerrit Holl wrote:
> Christoph Becker-Freyseng wrote:
>> 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
> Another possibility, which I have put in the Pre-PEP, is;
> We can add a method .openwith(), which takes a callable as it's first
> argument: p.openwith(f, *args) would result in f(str(p), *args). This
> would make p.open(*args) a shorthand for p.openwith(file, args).
> What do you think?
openwith would be a nice add-on. I see two problems with it:
1.) it's long. I mean
is shorter than
I got an idea of shortening this and making it look a bit like shell
(I'm not convinced of it very much, but I didn't want to keep it secret
--- maybe others like it ...)
path > (f, arg1, arg2, ...)
(this works by overwriting path.__gt__)
2.) the position of the argument for the path can only be the first one.
(maybe one could misuse even more operators e.g. the __r...__ ones; But
I think this will result in obscure code)
path.open shouldn't always call the ordinary file-constructor. I mean it
should be changed for special path-classes like FTPPath ...
(Of course for ordinary file-paths the ordinary file-class is the right
>>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)
> It may be a good idea to do so. At first, I didn't understand what it
> meant, an 'invalid path', but let's define it as anything that triggers
> a TypeError when passed to open or listdir. On POSIX, I know only one
> case: \0 in path. It may be a lot more difficult on Windows or the Mac.
> I'm not sure about this idea yet.
But it could avoid a lot of trouble when accessing the path.
Maybe I've a better idea (see below)
>>Especially if someone uses string-methods on a Path-object there could
>>arise invalid paths, even if finaly the path is valid again.
> Yes. But I can't really think of a use case for doing operations on a
> path which make it invalid. Does it occur in practice?
It easily happens on old FAT-FS. Think of a function that wants to
expand paths e.g.: (this is kind of "string-based")
path[:-2] + 'file1.txt',
path[:-2] + 'game.exe',
But probably sometimes stuff like this is useful.
Additionaly path-validity is filesystem-dependend. And worse on system
like Linux there can be more than one file system within the same root /
and they all could have different restrictions!
(if I were a viscious guy I could even umount and mount a different fs
making a valid path possibly invalid)
So I think the better solution would be to define a
method. It would just evaluate on call (which makes it unlikely that
things change during call and usage of the result -- without locking a
file/dir more isn't possible)
We also need a
I'm not sure how both should interact ??
Should Path be immutable like string?
More information about the Python-list