[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