[Python-Dev] The path module PEP
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