[Python-3000] Path Reform: Get the ball rolling

[Talin]

Greg Ewing wrote:
> Talin wrote:
>> And that includes path strings read from config files, not just path 
>> objects.
> 
> This is something new. I hadn't realised anyone
> was considering that to be within the scope of
> any of the proposed path modules.
> 
> Obviously this is going to require defining a
> standard external representation for paths.
> What do you envisage such a representation
> being like?

Hmmm, maybe it is new.

Let me take a moment to describe my motivations in this discussion. One 
of the reasons I really enjoy writing in Python is that I don't have to 
care what platform I am on. I use OS X at home and Win32 at work -- I'd 
like to be able to write code that works transparently on both systems.

It doesn't matter to me whether paths are represented as objects, or as
strings. What I'd really like is to be able to represent and manipulate
paths in a platform-agnostic way, and do so with code that is both easy
to read and concise.

But that model can't be restricted to just the objects contained within
the Python interpreter, we have to be able to read and write paths that
are coming from the external environment. In many instances, those will 
be paths that are in a platform-specific format; but, given a choice, I
am sure that many of us would prefer our data to be platform-neutral.

One thing to note is that there doesn't have to be just one single 
platform neutral representation. For example, lets suppose we're writing 
a Python script to interpret Perforce configuration files (which happens 
a lot in my environment.) A typical Perforce mapping has two parts, a 
depot part and a local part:

//depot/projects/metabuilder/src/... //myroot/dev/src/...

These 'paths' are the same regardless of what host you happen to be 
running on. If you plan on doing anything intelligent with them (like 
scanning for differences with the locally checked-out files or 
something), you'll probably want to translate them into some form that 
the local filesystem can interpret.

So here we have an example of an already-existing, platform-neutral 
representation of paths, but I would never suggest that Python adopt 
wholesale the Perforce representation of paths as the only 
platform-neutral solution.

One might ask - is it the responsibility of the Python standard path 
module to even deal with such things? Since these are not sanctioned 
operating system paths, why should Python have a responsibility to 
support them? That's a good argument, but on the other hand - it's 
awfully convenient to be able to use the existing os.path to process 
stuff like this, especially considering the possibility that folks who 
roll their own Perforce-specific path functionality might 'get it wrong' 
in some subtle way.

One way to solve this would be to define a platform-neutral path 
representation that can be "rendered" into either os-specific *or* 
application-specific formats. I could read a Perforce path string, 
convert that into an abstract path, do some work on it, and then convert 
it back to a Perforce path - or convert to a local filesystem path if I 
choose. Basically we'd have importers and exporters (format converters) 
for paths. On Win32, for example, we could have an "NT" importer for 
standard NT-style paths; a "Cygwin" importer that was more relaxed about 
a mixture of forward- and back-slashes; and so on.

Of course, there would always be a "shortcut" for the local filesystem 
format - i.e., if no conversion was specified, then the local host 
format would be used as the default.

How such importers and exporters would actually look syntactically, I am 
not sure yet. I'm open to ideas...

-- Talin