[Python-Dev] The path module PEP
stefan.rank at ofai.at
Fri Jan 27 11:47:21 CET 2006
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.
I see your point.
I guess there are two options:
- `Path` as an enhanced string type that bundles methods related to file
- `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
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
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.
More information about the Python-Dev