[Python-Dev] os.path.diff(path1, path2)

[Matthias Andreas Benkard]

Hi,

> IMO, the relpath method should just work textually on
> the pathnames. It's up to the user to ensure it makes
> sense to do so, e.g. by resolving symlinks beforehand
> if necessary.

I guess so. Don't forget to mention this quirk in the docs, though :)

> The alternative would be for relpath to do this itself,
> but that would make it very unusual compared to the
> other path-munging functions, none of which touch the file
> system.

Yes, and this behaviour would make it unusable for virtual file systems
within the application, too. Path names needn't refer to the local file
system, right? Then again, the `os' module _is_ platform-specific, as is
`os.path', so one shouldn't use it for those things either way.

In fact, relpath _cannot_ dereference symlinks on its own, as it has no
way of knowing the absolute pathname if only relative pathnames are
given as arguments (for example, relpath("a/b/c", "../d")).

But this begs the question: What is relpath good for, anyway? And what
are the hidden costs? One-time scripts might benefit from it, but having
this function in the standard library could make application developers
use it without considering the consequences, resulting in strange bugs
that occur on one machine, but not on another. The more I think about
it, the more I'm afraid that this might lead to severe security
vulnerabilities if misused in tools run by the system administrator.

Better place a big, fat warning in the docs, then.

Bye,
Matthias


________________________________________________________________________

 Matthias Andreas Benkard, Anarchokommunist und Pythonprogrammierer

Persönliche Website: http://www.mulk.de.vu/
Persönlicher Weblog: http://www.kompottkin.de.vu/
Flames bitte nach /dev/null schicken.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20050920/278daca3/attachment.pgp