PRE-PEP: new Path class
gerrit at nl.linux.org
Tue Jan 6 20:39:51 CET 2004
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?
> 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?
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:
More information about the Python-list