PRE-PEP: new Path class

[Gerrit Holl]

Christoph Becker-Freyseng wrote:
> 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
-- 
PrePEP: Builtin path type
    http://people.nl.linux.org/~gerrit/creaties/path/pep-xxxx.html
Asperger's Syndrome - a personal approach:
	http://people.nl.linux.org/~gerrit/english/