PRE-PEP: new Path class

[Christoph Becker-Freyseng]

Gerrit Holl wrote:
> Christoph Becker-Freyseng wrote:
> 
>>[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).
> 
> 
> 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
    f(str(path), *args)
    is shorter than
    path.openwith(f, *args)
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 
one.)
> 
>>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")

def myfiles(path):
	if path.endswith('*'):
		return [
			path[:-2] + 'file1.txt',
			path[:-2] + 'game.exe',
			]
	else:
		return path

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
path.isValid()
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
path.exists()
method.

I'm not sure how both should interact ??


Another Point:
Should Path be immutable like string?




    Christoph Becker-Freyseng