[Python-3000] Mini Path object

[Talin]

Bill Janssen wrote:
> Greg Ewing writes:
>> If the standard format were designed so as to be
>> unambiguously distinguishable from all native
>> formats, ...
> 
> All native formats both past and future.

That's not difficult.

I use 'posix' paths as my universal format. I convert them to native
paths just before writing them out or passing to a subsystem that
requires native paths.

For reading paths, it depends on whether the paths are already in
universal (posix) style or native style. If they are native, I use one
method for reading them, if they are universal I use a different method
(Well, in the current code base that's not true - since os.path always
handles paths in posix format as well as native format, even when
running on non-posix systems. So I just pass everything to os.path and
it just works.)

What this means is that universal paths need never be serialized - they
are always converted to native form before being written anywhere. Which
in turn implies that the 'universal' path format can be an
in-memory-only format. And as such, it can express its 'universalness'
by additional object properties or object types, rather than via any
kind of weird string encoding.

Thus, a universal path is nothing more than a posix path, except with a
different object type.

Representing non-posix concepts such as drive letters is done simply by
not interpreting them; Or in some cases, deferring any interpretation
until the user specifically calls a function to split off that part. So
if you have a path beginning with "C:", it doesn't try to interpret what
that means until you ask it to via splitdrive().

(This is a good reason to have paths represented as strings instead of
as a tuple, since you can't defer interpretation this way with
pre-parsed paths.)

-- Talin