[Python-Dev] The path module PEP (original) (raw)

Stefan Rank stefan.rank at ofai.at
Thu Jan 26 17:55:24 CET 2006

on 26.01.2006 16:34 Aaron Bingham said the following:

Stefan Rank wrote:

on 26.01.2006 14:15 Paul Moore said the following: [snip]

Arguably, Path objects should always maintain an absolute path - there should be no such thing as a relative Path. you realise that one might need and/or want to represent a relative path? Of course, but it seems to me a relative path is a different type from an absolute path, in the same way that a timedelta is different from a datetime. For example: * You can't open a relative path without reference to some absolute path (possibly the cwd). * You can't join two absolute paths, but you can join a relative path to another relative path, or to an absolute path.

I think the datetime/timedelta analogy is not bad: A datetime is actually also a time delta - relative to some given start-time, internally this is normally the "epoch". For human-readable representations it is the birth of your chosen deity, or the creation of the universe, ...

The start time for datetime is implicit. Python has chosen some absolute reference.

For paths that absolute reference (the root) is very much context dependent (platform dependent). You can open a relative path - because processes always have an implicit cwd as part of their context.

But you might also want to represent paths that are relative on another host than the one your program is running on.

I don't think it makes sense to design a Path class that captures the abstract concept of a path - because of the semantic differences between unix paths, windows paths, URL paths, ...

I see the Path object as a special kind of string, that has helpful methods for relating it to the workings of filesystems in general and the local filesystem in particular. But it is still just an ordinary string that happens to be used as a special kind of address.

I try to separate the concept of the 'object in the filesystem' (which is the domain of Python's file objects) from the 'hierarchical address to an object' (which is what the Path objects make easier).

(Java has these two conflated in one.)

So, to get to the point, a file is a thing that should always have an absolute path. (and it does. it should probably grow a .path attribute in addition to .name ? This could return None for files without paths.) A Path should be able to contain absolute, relative, valid, as well as invalid (on a given OS) paths.

In case that future systems manage to reduce the importance of the legacy crutch that is the hierarchical filesystem ;-) we might get query-like addresses: '/tmp/[author=me;type=text/html]' and Path might grow to deal with it.

Sorry I digress.

+1 on Path as an enhanced string that bundles file-system-address related methods.

stefan

More information about the Python-Dev mailing list