PRE-PEP: new Path class

[John Roth]

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!)

In the issues section:

1) Should path be a subclass of str?

No. Outside of the difficulty of deciding whether it's a
subclass of single byte or unicode strings, it's a pure
and simple case of Feature Envy. Granted, there will
be times a developer wants to use string methods, but
the most common operations should be supported directly.

2) virtual file system extensibility.

No opinion at this time. I'd like to see a couple
of attempts at an implementation first before
settling on a single design.

3) Should the / operator map joinpath.

I agree. No way. In the first place, that's a unixism
(Windows uses \, the Mac uses In the second
place it doesn't fit the common use of /, which is
to divide (separate) things. If we want an operator
for join (not a bad idea) I'd suggest using '+'. String
already overloads it for concatenation, and as I said
above, I'd just as soon *not* have this be a subclass
of string.

4) Should path expose an iterator for listdir(?)

I don't see why not, as long as the path is to a
directory.

5) Should == operator be the same as os.path.samefile()?

Why not...

6) Path.open()?

Of course.

7) Should the various gettime methods return Datetime
objects.

Of course.

8) Touch method?

Of course.

9) Current OS constants?

What are they? Are we talking about the four
constants in the access() function, or about something
else?

10) Commonprefix, walk and sameopenfile?

Commonprefix should be a string or list method,
it doesn't fit here.

walk is a nice function, but it should be redone to
use the visitor pattern directly, with different method
names for files, directories and whatever else a
particular file system has in it's warped little mind.

sameopenfile doesn't belong in the os.path module
in the first place. It belongs in the os module under
6.1.3 - File Descriptor Operations.

11) rename join and split.

I wouldn't bother. Since I'm against making it a
subclass of str(), the issue doesn't arise.

12) Should == compare file sizes.

No. Might have a method to do that.

13) chdir, chmod, etc?

No. This has nothing to do with pathname.

14. Unicode filenames

Have to have them on Windows and probably
on the Mac.

15. Should files and directories be the same
class.

Probably not. While they share a lot of common
functionality (which should be spelled out as an
interface) they also have a lot of dissimilar
functionality. Separating them also makes it easy
to create objects for things like symbolic links.

In addition to this, we should have the ability
to update the other times (utime()) directly
using another file or directory object as well
as a Datetime object.

John Roth

 

[Just]

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!)

In the issues section:

[ snipping those points where I agree with John ]

4) Should path expose an iterator for listdir(?)

I don't see why not, as long as the path is to a
directory.

_An_ iterator, sure, but not __iter__. How about path.listdir()?
__iter__ could also iterate over the path elements, so it's ambiguous at
least.

15. Should files and directories be the same
class.

Probably not. While they share a lot of common
functionality (which should be spelled out as an
interface) they also have a lot of dissimilar
functionality. Separating them also makes it easy
to create objects for things like symbolic links.

But what about paths for not-yet-existing files of folders? I don't
think you should actually _hit_ the file system, if all your doing is
path.join().

Just

 

[John Roth]

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!)

In the issues section:

[ snipping those points where I agree with John ]

4) Should path expose an iterator for listdir(?)

I don't see why not, as long as the path is to a
directory.

_An_ iterator, sure, but not __iter__. How about path.listdir()?
__iter__ could also iterate over the path elements, so it's ambiguous at
least.

I see what you're saying. I'd argue (softly) that iterating over
the directory entries is the natural interpretation, though.

But what about paths for not-yet-existing files of folders? I don't
think you should actually _hit_ the file system, if all you're doing is
path.join().

I agree here. I haven't looked at any of the candidate implementations
yet, so I don't know what they're doing. I'm thinking of a
three class structure: the parent class is just the path manipulations;
it has two subclasses, one for real files and one for real directories.
That way they can not only inherit all of the common path manipulation
stuff, but the developer can instantiate a pure path manipulation
class as well.

There might also be a mixin that encapsulates the stuff that's common
to real files and directories like accessing and changing dates and
permissions.

I'm sure there are use cases that will throw a curve at that structure
as well.

 

[Just]

_An_ iterator, sure, but not __iter__. How about path.listdir()?
__iter__ could also iterate over the path elements, so it's ambiguous at
least.

I see what you're saying. I'd argue (softly) that iterating over
the directory entries is the natural interpretation, though.[/QUOTE]

It's far too implicit to my taste; for one since it's a folder-only
operation (and I don't see much merit in having separate classes for
folder and file paths). Would you also be in favor of interating over
file-paths meaning iterating over the lines in the file?

Just

 

[Mike C. Fletcher]

....


I agree here. I haven't looked at any of the candidate implementations
yet, so I don't know what they're doing. I'm thinking of a
three class structure: the parent class is just the path manipulations;
it has two subclasses, one for real files and one for real directories.
That way they can not only inherit all of the common path manipulation
stuff, but the developer can instantiate a pure path manipulation
class as well.

There might also be a mixin that encapsulates the stuff that's common
to real files and directories like accessing and changing dates and
permissions.

I'm sure there are use cases that will throw a curve at that structure
as well.

My implementation combines the two into a single class. Here's the logic:

* There is no necessary distinction between files and directories at
the path level
o Particularly with upcoming ReiserFS 4, where structured
storage shows up, it's possible to have files behaving much
like directories.
o Zip files also come to mind if we have virtual file system
support eventually
* These objects represent paths, not the things pointed to by the paths.
o They allow you to operate on the path, which is "almost" the
filesystem, but not quite.
o In the space of "paths", there's no distinction between a
file and a directory, really.
o Even a path that traverses a few symbolic links, and drops
into a zip-file is still just a path, it's a way of
specifying something, similar to a "name" or "location" class.
o You can find out what the path-object points to via the path
methods, but the path itself isn't those objects.
* Don't want to have to explicitly cast your paths to file/directory
to get the basic file/directory operations when joining paths.
o Mix-ins require changing the class of the instance by
somehow figuring out that it's a file, that requires a
file-system access (to what may be a non-existent or very
expensive-to-access file).
o There's not much of a conflict between the file/directory
path operations

Enjoy,
Mike

_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/

 

[Mike C. Fletcher]

John Roth wrote:
....

1) Should path be a subclass of str?

No. Outside of the difficulty of deciding whether it's a
subclass of single byte or unicode strings, it's a pure
and simple case of Feature Envy. Granted, there will
be times a developer wants to use string methods, but
the most common operations should be supported directly.

It's not the methods that make me want to use str/unicode as the base,
it's the ability to pass the resulting instances to built-in methods
that explicitly expect/require str/unicode types. Not sure how many of
the core functions/libraries still have such requirements, but I'd guess
it's a few.

That said, I don't mind making path it's own base-class, I just *really*
want to be able to pass them to path-unaware code without extra coercian
(otherwise switching a module to *producing* paths instead of raw
strings will cause the *clients* of that module to break, which is a
serious problem for rapid adoption).

3) Should the / operator map joinpath.

Agreed, no. As for using + for join, that will break a lot of code that
does things like this:

p = mymodule.getSomeFilename()
backup = p + '.bak'
copyfile( p, backup )
open( p, 'w').write( whatever )

i.e. we're thinking of returning these things in a lot of situations
where strings were previously returned, string-like operations should
IMO, be the norm. But then we disagree on that anyway .

4) Should path expose an iterator for listdir(?)

I don't see why not, as long as the path is to a
directory.

Seems ambiguous to me. Also seems silly to use a generator when we're
producing a list anyway from the underlying call, might as well return
the list to allow length checks and random access. Iterators for
"ancestors" might be useful, but again, doesn't really seem like it
needs to be __iter__ instead of "ancestors".

5) Should == operator be the same as os.path.samefile()?

Why not...

__eq__ sounds about right. I gather this call goes out to the
filesystem first, though. Might be good to first check for absolute
equality (i.e. the same actual path) before doing that.

6) Path.open()?

Of course.

Ditto.

7) Should the various gettime methods return Datetime
objects.

Of course.

What are we doing for Python 2.2 then? I agree with the principle, but
we should likely have a fallback when datetime isn't available.

8) Touch method?

Of course.

Neutral, seems fine.

9) Current OS constants?

What are they? Are we talking about the four
constants in the access() function, or about something
else?

Don't know myself.

10) Commonprefix, walk and sameopenfile?

Commonprefix should be a string or list method,
it doesn't fit here.

Path commonprefix are different operations from str commonprefix. Paths
should only accept entire path-segments (names) as being equal, while
strings should accept any set of characters:

'/this/that/those/them'
'/this/thatly/those/them'

should see '/this/' as the commonprefix for the paths, not '/this/that'.

walk is a nice function, but it should be redone to
use the visitor pattern directly, with different method
names for files, directories and whatever else a
particular file system has in it's warped little mind.

Reworking walk is probably a good idea. I'll let others worry about it,
as I've re-implemented the functionality so many times for my own code
that I'm just sick of it .

11) rename join and split.

I wouldn't bother. Since I'm against making it a
subclass of str(), the issue doesn't arise.

No real preference one way or another here. join -> "append" for paths
seems fine. split -> "elements" or "steps" for paths also seems fine.

12) Should == compare file sizes.

No. Might have a method to do that.

Agreed, though even then, if we have a method that returns file-sizes:

path( ... ).size() == path( ... ).size()

seems almost as reasonable as having a method for it?

13) chdir, chmod, etc?

No. This has nothing to do with pathname.

chmod has to do with altering the access mode of a file/directory by
specifying it's path, no? Seems like it could readily be a method of
the path. chdir should accept a path, otherwise doesn't seem like it
should be a method.

14. Unicode filenames

Have to have them on Windows and probably
on the Mac.

Yes.

15. Should files and directories be the same
class.

Replied to this in the sub-thread...

Enjoy all,
Mike

_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/

 

[Oren Tirosh]

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!)

"Peroperly"? There is nothing particularly "proper" or "improper"
about objects or any other programming paradigm supported by Python.
Objectifying is not a goal in itself. I like the Path object because
the interface is easier to learn and use, not because it is
"objectified".

5) Should == operator be the same as os.path.samefile()?

Why not...

No. Symbolic links are something you would sometimes want to treat as
distinct from the files they point to.

walk is a nice function, but it should be redone to
use the visitor pattern directly, with different method
names for files, directories and whatever else a
particular file system has in it's warped little mind.

I find a generator and a couple of elifs are much easier to read. No
need to define a class, pass context information to the methods of
that class, etc.

13) chdir, chmod, etc?

No. This has nothing to do with pathname.

What's the difference between chmod and touch? They both affect the
file metadata in similar ways.

Oren

 

[Gerrit Holl]

Subject: PRE-PEP: new Path class

I'm adding a thread for comments on Gerrit Holl's pre-pep, which
can be found here:

http://tinyurl.com/2578q

I will update the Pre-PEP tomorrow based on the comments I already have
seen in this PEP. Note that it is very 'pre' and opinions expressed in
the PEP are not guaranteed to be consistent in any way

I will comment on the comments later.

yours,
Gerrit.

 

[John Roth]

John Roth wrote:
...

It's not the methods that make me want to use str/unicode as the base,
it's the ability to pass the resulting instances to built-in methods
that explicitly expect/require str/unicode types. Not sure how many of
the core functions/libraries still have such requirements, but I'd guess
it's a few.

That said, I don't mind making path it's own base-class, I just *really*
want to be able to pass them to path-unaware code without extra coercian
(otherwise switching a module to *producing* paths instead of raw
strings will cause the *clients* of that module to break, which is a
serious problem for rapid adoption).

That's an excellent point, but it begs the question of which
string class it should subclass. Unless it's got some way of
changing its base class depending on the system it's running
on. That, in turn, probably violates the Principle of Least
Astonishment.

__eq__ sounds about right. I gather this call goes out to the
filesystem first, though. Might be good to first check for absolute
equality (i.e. the same actual path) before doing that.

I think this has to do with "conceptual integrity." Are we talking
about a path object that happens to have the ability to do file
system operations in appropriate circumstances, or are we talking
about a file system object that includes all of the usual path
manipulations? You seem to be thinking of the first approach,
and I'm thinking of the second. You're beginning to convince me,
though.

What are we doing for Python 2.2 then? I agree with the principle, but
we should likely have a fallback when datetime isn't available.

Do we care? If this is going into Python, it will be in 2.4 at the
earliest, with a possible addon to a late 2.3 release. I don't see
it going into 2.2 at all, although a backwards version would
be nice.

Path commonprefix are different operations from str commonprefix. Paths
should only accept entire path-segments (names) as being equal, while
strings should accept any set of characters:

'/this/that/those/them'
'/this/thatly/those/them'

should see '/this/' as the commonprefix for the paths, not '/this/that'.

Good point if you're thinking of heterogenous collections. If you're
thinking (as I am) that an object can represent a directory, then it
seems like a singularly useless method.

Reworking walk is probably a good idea. I'll let others worry about it,
as I've re-implemented the functionality so many times for my own code
that I'm just sick of it .

I can understand that. [grin]

chmod has to do with altering the access mode of a file/directory by
specifying it's path, no? Seems like it could readily be a method of
the path.

Right. I forgot that these are two totally different issues.

chdir should accept a path, otherwise doesn't seem like it
should be a method.

If the path object describes a directory, then I'd see
a .chdir() method as useful. Otherwise, it belongs
somewhere else, although I don't have a clue where
at the moment.

Enjoy all,
Mike

John Roth

 

[Dan Bishop]

I'm adding a thread for comments on Gerrit Holl's pre-pep, which
can be found here:

http://tinyurl.com/2578q
....
1) Should path be a subclass of str?

No.

So will the file constructor be "overloaded" to accept path objects?
What about all those functions in the os module?

 

[Just]

[Mike C. Fletcher]
[John Roth]

That's an excellent point, but it begs the question of which
string class it should subclass. Unless it's got some way of
changing its base class depending on the system it's running
on. That, in turn, probably violates the Principle of Least
Astonishment.

That's in fact exactly what Jason Orendorff's path module does. But it's
buggy due to os.path.supports_unicode_filenames being buggy.

It would be interesting to figure out to what extent non-string (and
non-unicode) path objects can or can't be made to work for existing
string-accepting code. I would very much prefer a path _not_ to inherit
from str or unicode, but Mike's point is an important one. What is
missing in Python to allow non-string objects to act like (unicode)
strings?

Just

 

[Christoph Becker-Freyseng]

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

 

[Christoph Becker-Freyseng]

...



So will the file constructor be "overloaded" to accept path objects?
What about all those functions in the os module?

IMO this is the bettter way.
However it might be useful for transition subclass str. (see my other
posting)

 

[Gerrit Holl]

Hi,

I have updated the PEP, partly based on comments by other, partly on my
own thoughts. Tinyurl seems down, the latest version is available at:

http://people.nl.linux.org/~gerrit/creaties/path/pep-xxxx.html

yours,
Gerrit.

 

[Gerrit Holl]

Don't know myself.

I meant os.path constants: curdir, pathsep, defpath, etc.
They should be included.

Reworking walk is probably a good idea. I'll let others worry about it,
as I've re-implemented the functionality so many times for my own code
that I'm just sick of it .

I think os.walk is good as it is.

yours,
Gerrit.

 

[Gerrit Holl]

_An_ iterator, sure, but not __iter__. How about path.listdir()?
__iter__ could also iterate over the path elements, so it's ambiguous at
least.

I think it should be called .list(): this way, it is better extendable
to archive files like zip and tar. Indeed: I know at least 3 different
possibilities for path.__iter__. Because of "In the face of ambiguity,
refuse the temptation to guess.", I think there should be no __iter__
(which is even another reason not to subclass __str__, by the way) [0].

But what about paths for not-yet-existing files of folders? I don't
think you should actually _hit_ the file system, if all your doing is
path.join().

Another problem is dat I may not know whether I have a file or a
directory. If a directory is a different type than a file, it would
probably have a different constructor as well, and I may end up doing:

p = path(foo)
if p.isdir():
p = dirpath(foo)

If this is done implicitly, you can't create a path without
fs-interaction, which is bad for virtual-fs extensibility and confusing
if it doesn't mean a path always exists [1].

[0] http://people.nl.linux.org/~gerrit/creaties/path/pep-xxxx.html#for-foo-in-mypath
[1] http://people.nl.linux.org/~gerrit/creaties/path/pep-xxxx.html#absent-paths

yours,
Gerrit.

 

[Gerrit Holl]

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

 

[Gerrit Holl]

[PEP]
[John Roth]
I was hasitating, because of the backwards-compability, but this should
not be a reason not to make things better, of course (TV isn't backward
compatible with radio either

[Mike C. Fletcher]
[John Roth]

Do we care? If this is going into Python, it will be in 2.4 at the
earliest, with a possible addon to a late 2.3 release. I don't see
it going into 2.2 at all, although a backwards version would
be nice.

If the PEP will be finished and may be accepted, I think that the
roadmap of introducing the feature will be like sets: In 2.4, it's a
library, and if it's succesful/popular, it may become a builtin in 2.5.

In should... it doesn't seem to do so currently.

Good point if you're thinking of heterogenous collections. If you're
thinking (as I am) that an object can represent a directory, then it
seems like a singularly useless method.

The only place where I can think of a use is a tarfile/zipfile. For a
path, it means nothing. It can be useful but since it needs multiple
paths, it can't be a method. The only thing I can think of is a
classmethod, a constructor, but I don't really like the idea much.

Is p.chdir() better or worse than chdir(p)?
The latter reads better, but that may be because we're used to it.
But on the other hand, that may be a convincing argument just as well

If the path object describes a directory, then I'd see
a .chdir() method as useful. Otherwise, it belongs
somewhere else, although I don't have a clue where
at the moment.

I think there should be no distinction between files and directories,
and that p.chdir() for a non-directory should raise the same exception
as currently (OSError Errno 20).

yours,
Gerrit.

--
27. If a chieftain or man be caught in the misfortune of the king
(captured in battle), and if his fields and garden be given to another and
he take possession, if he return and reaches his place, his field and
garden shall be returned to him, he shall take it over again.
-- 1780 BC, Hammurabi, Code of Law

 

[Bernhard Herzog]

5) Should == operator be the same as os.path.samefile()?

Why not...

ISTM, that it would essentially make path objects non-hashable.
posixpath.samefile compares the os.stat values for both filenames.
These values can change over time vor various reasons so object equality
changes too. That it changes is desired, obviously, but what do you use
as hash value? p1 == p2 has to imply that hash(p1) == hash(p2) but the
only way to achieve that is to give all path objects the same hash
value. That would make dicts with path objects as keys very
inefficient, though.

As for the path objects in general: Cute idea, but IMO strings for
filenames work fine and there's nothing unpythonic about it. The
virtual filesytem bit seems like a good reason not to introduce the path
type just yet:

2) virtual file system extensibility.

No opinion at this time. I'd like to see a couple
of attempts at an implementation first before
settling on a single design.

At this point it doesn't seem clear what virtual filesystems would mean
for Python, so it's unclear, too, what it would mean for a Path class.
Introduce a Path class once there is a need for having several distinct
classes, not earlier.

Bernhard

 

[Gerrit Holl]

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)

This is indead a disadvantage. On the other hand, although p.openwith is
longer, I do think it is more readable. It occurs often that shorter is
not more readable: just think of all those 'obfuscated-oneliners'
contests in C and Perl.

path > (f, arg1, arg2, ...)

(this works by overwriting path.__gt__)

I think this is not a good idea. In my opinion, any __gt__ method should
always compare, no more, no less. Further, it's very unusal to call
something like this.

Another possibility is defining __call__:

path(f, *args) == f(str(path), *args)

which may be unconvinient as well, however. Is it intuitive to let
calling mean opening?

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)

Hm, I think almost all file constructors have the path as the first
argument. Are there counter-examples?

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

Yes... I was planning to define it in a class which is able to 'touch'
the filesystem, so an FTPPath could subclass basepath without the need
to overload open, or subclass ReadablePath with this need.

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)

I think this makes validating a path essentially impossible to get
right. Let's say we can declare path to be invalid, but we can't declare
a path to be valid. Is it a good thing to add a method for it then? (I
think yes)

So I think the better solution would be to define a
path.isValid()

I agree that it's better. We should allow invalid paths after all.

We also need a
path.exists()
method.
Sure.

I'm not sure how both should interact ??

Well, if path.exists(), path.isValid(). The question is - should
path.isValid() read the filesystem?

Another Point:
Should Path be immutable like string?

I have though about this, too. It should certainly not be fully mutable,
because if a path changes, it changes. But maybe we could have a
..normalise_inplace() which mutates the Path? What consequences would
this have for hashability?

I like paths to be hashable. so they probably should be immutable.

yours,
Gerrit.

--
16. If any one receive into his house a runaway male or female slave of
the court, or of a freedman, and does not bring it out at the public
proclamation of the major domus, the master of the house shall be put to
death.
-- 1780 BC, Hammurabi, Code of Law