[Python-3000] Mini Path object

[Mike Orr]

On 11/9/06, Talin <talin at acm.org> wrote:
> 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.)

Er, is there an API recommendation in there somewhere, or is this just
philosophy or usage style?

Posix is the lingua franca of the current age, and the non-compliant
OSes (Windows and Mac) have various levels of compatibility with it.
So using Posix in portable config files is justifiable.

However, a list of components works better as an intermediate format
for autoconverting.  You're going to get lists anyway with .split()
and .join().  There's no reason to convert from format A to Posix to
format B.  If we define the first component as the absolute root or
'', the source format knows how to convert it to that, and the
destination format will at least recognize it as an  even if it
doesn't know what it means.  That's enough information to raise an
exception or convert the path to relative.

-- 
Mike Orr <sluggoster at gmail.com>