On Sat, 6 Oct 2012 11:27:58 +0100 Paul Moore
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