PRE-PEP: new Path class; isValid, exists

Christoph Becker-Freyseng webmaster at
Thu Jan 8 23:44:56 CET 2004

Gerrit Holl wrote:

> Christoph Becker-Freyseng wrote:
>>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
> I agree that it's better. We should allow invalid paths after all.
Yes. path.isValid would it make possible to check better for situations 
were calling things like mkdir and mkdirs (they directly depend on the 
path being valid) makes trouble.
We could also add an InvalidPathException. Which will at least help 
debugging. isValid could have a default argument "raiseExc=False" to 
make checking in these functions convienent e.g.
def mkdir(self):
	moreStuff ...
If the path is invalid it will stop with an InvalidPathException.

Also path.exists should depend on path.isValid (not the other way).
If the full-path doesn't exist one can go up all the parent-dirs until 
one exist. Here we can check if the specified sub-path is valid by 
getting some information about the filesystem where the parent-dir is 
stored. *this implicit makes isValid a reading method* --- however AFAIK 
isValid is only needed for reading and writing methods.
>>We also need a
> Sure.
>>I'm not sure how both should interact ??
> Well, if path.exists(), path.isValid(). The question is - should
> path.isValid() read the filesystem?
Yes as stated above.

path.exists should at first check if the path isValid at all. If it 
isn't a statement about it's existance is senseless. In this case it 
should return None, which evaluates also False but is different  (it's a 
"dreiwertige Logik" --- when you have 3 states (true, false, unknown) 
how is this called in English)

FIXME: We have to finetune the "recursive" behavior of isValid and 
exists otherwise we have a lot of unnecessary calls as exists and 
isValid call each other going one dir up ...

Christoph Becker-Freyseng

More information about the Python-list mailing list