PRE-PEP: new Path class

[Gerrit Holl]

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?

> 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.

> 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?

yours,
Gerrit.

-- 
123. If he turn it over for safe keeping without witness or contract,
and if he to whom it was given deny it, then he has no legitimate claim.
          -- 1780 BC, Hammurabi, Code of Law
-- 
Asperger's Syndrome - a personal approach:
	http://people.nl.linux.org/~gerrit/english/