[Python-3000] Mini Path object

[Talin]

Mike Orr wrote:
> 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.
>>

(much useless Talin blathering omitted)

>> (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?

I am indeed trying to describe a usage style, one that is not only used 
by me but by a large number of pre-existing apps. My goal in describing 
this is to insure that any new path system allows similar kinds of usage 
patterns.

What I am arguing against is an overly strict and pedantic 
interpretation of the differences in path representation across 
platforms. True, in theory, you can't compare a windows path with a 
posix path, but in practice it generally "just works".

I sometimes notice a tendency on this list that anything which is not 
100% provably correct should be forbidden, no matter how useful it is.

Let me give a concrete example: In my TurboGears project, there is a 
file called "thes.egg-info/sqlobject.txt" that contains this string:

	history_dir=$base/thes/sqlobject-history

I didn't write this, it was generated by the 'quickstart' script. I 
fully expect to be able to package up my TG app from my OSX machine, 
transport it to my Windows box, and have it work. And I would fully 
expect to be able to do the same in any future version of TurboGears 
running on a future version of Python.

Now, one can argue that this string is meaningless when taken from one 
platform to another, but the only thing that is accomplished by that 
argument is to remove functionality that current users find useful and 
valuable.

I could bring up other examples, but do I really need to? (And would you 
really want to read them?)

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

I don't have a problem with this.

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

The way I tend to deal with these kinds of issues is to let the 
"absolute" part of the path be an opaque blob that is uninterpreted by 
me or my code. Code that does path algebra is really only interested in 
the 'tail' of the path (except in cases where you have an absolute 
override during a combine). So it really doesn't matter to me what the 
'head' part looks like - I just leave it alone and don't worry about it.

-- Talin