[Python-3000] Mini Path object

Greg Ewing greg.ewing at canterbury.ac.nz
Fri Nov 10 01:18:34 CET 2006


Talin wrote:

> Bill Janssen wrote:
>
> > All native formats both past and future.
>
> That's not difficult.
 >
 > I use 'posix' paths as my universal format.

That assumes you can always distinguish a posix path from
some other kind of path. That's not always the case,
e.g. consider

   /hello:wide/world

Is that a posix path or not? It could be, but it could
also be a classic MacOS pathname referring to a file
called "wide/world" on a volume called "/hello".

It's fine if there's a rule that all paths in your
config file are in the universal format. But we were
talking about allowing the user to use either native
or universal format.

> 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.

Hmmm, we seem to have crossed topics again -- I thought
we were talking about storing paths in config files.

> os.path always
> handles paths in posix format as well as native format, even when
> running on non-posix systems.

Really? I wasn't aware of that. I don't see how it *can*,
given what I said above.

If you're talking about the way you can use forward or
backward slashes on Windows, that's a property of the
Windows kernel, not os.path. And it only applies to
Unix vs. Windows, not in general.

> 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().

What if you need to know whether it's an absolute or
relative path, e.g. so you can join it to another path?
You can't do that without knowing something about the
semantics.

--
Greg


More information about the Python-3000 mailing list