[Python-Dev] The path module PEP

[Stefan Rank]

on 27.01.2006 11:16 Paul Moore said the following:
> [...]
>>> Arguably, Path objects should always maintain an absolute path - there
>>> should be no such thing as a relative Path. So you would have
>> you realise that one might need and/or want to represent a relative path?
> 
> Absolutely. But not a Path (see distinction above).
> 
> Aaron Bingham's analogy with time/timedelta applies well here.
> Relative paths, like relative times, have their own special semantics,
> which deserve to be addressed in a separate class.
> 
> You argue that time is "merely" a timedelta with a fixed start point.
> I'd disagree - the key point with timedeltas is that they need careful
> handling (DST issues, for example) _depending upon precisely what they
> are added to_ - these issues are avoided by the time type exactly
> because it has a constant base. In exactly the same way, absolute
> paths have simpler semantics precisely because they are absolute.
> 
> Paul.

I see your point.

I guess there are two options:

- `Path` as an enhanced string type that bundles methods related to file 
system addressing

- `Path`s that accurately reflect the possible (abstract) paths. There 
would be a Path and a PathDelta (with appropriate combining semantics), 
and probably a UnixPath, a WindowsPath, an URLPath maybe. And there need 
to be appropriate methods for combining them with/creating them from 
strings.

I actually think the latter would be very neat and somewhere else in 
this thread someone talks about his `Tree` - `Path` - `File` classes 
with specialised subclasses.

The first option, however, has the benefit of simplicity and there is a 
working implementation.

Well - I'm not the one to decide. And I think anything that bundles path 
related stuff (using a little object-orientation) and cleans up the 
standard library is a step forward.

cheers,
s