[Python-ideas] PEP 428 - object-oriented filesystem paths

[Antoine Pitrou]

On Sat, 6 Oct 2012 11:27:58 +0100
Paul Moore <p.f.moore at gmail.com> wrote:
> 
> > I would expect "relative" to require an argument.  (Ie, I
> > would expect it to have the semantics of "relative_to".)
> 
> I agree that's what I thought relative() would be when I first read the name.

You are right, relative() could be removed and replaced with the
current relative_to() method. I wasn't sure about how these names would
feel to a native English speaker.

> > Or is the
> > issue that you can't count on PureNTPath(p).relative_to('C:\\') to
> > DTRT?
> 
> It seems to me that if p isn't on drive C:, then the right thing is
> clearly to raise an exception.

Indeed:

>>> PureNTPath('/foo').relative_to('c:/foo')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "pathlib.py", line 894, in relative_to
    .format(str(self), str(formatted)))
ValueError: '\\foo' does not start with 'c:\\foo'


> No ambiguity there - although Unix
> users might well write code that doesn't allow for exceptions from the
> method, just because it's not a possible result on Unix.

Actually, it can raise too:

>>> PurePosixPath('/usr').relative_to('/usr/lib')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "pathlib.py", line 894, in relative_to
    .format(str(self), str(formatted)))
ValueError: '/usr' does not start with '/usr/lib'


You can't really add '..' components and expect the result to be
correct, for example if '/usr/lib' is a symlink to '/lib', then
'/usr/lib/..' is '/', not /usr'.

That's why the resolve() method, which resolves symlinks along the path,
is the only one allowed to muck with '..' components.

Regards

Antoine.


-- 
Software development and contracting: http://pro.pitrou.net