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

[Talin]

The thread on python-dev with respect to PEP 355 seems to have died out, 
so I thought it might be a good time to move things over here.

What I'd like to do is to start by examining the most fundamental 
assumptions about refactoring os.path and the various other path-related 
functions. Before we even begin to write a new PEP, I want to at least 
make sure that consensus is even possible - even though we may not all 
be on the same page (to use a tired metaphor), we're at least reading 
from the same book :)

Let me break this down into a number of questions:

1) Does os.path need to be refactored at all? I think most people agree 
that os.path isn't perfect, but IMHO it isn't terrible either - you can 
get work done with it, and its not really that hard to learn.

 From my own experience, I've often run into cases where I overlooked 
some critical feature of the standard library, and ended up looking 
foolish after posting my question on the python mailing lists, only to 
discover that the answer was there all along (kind of like Dorothy's red 
slippers in that way.) But I've not yet had an occasion, as far as I can 
recall, where the os.path module was the culprit.

2) Putting aside for the moment the issue of syntactic sugar, 
convenience, code beauty, and ease of learning, is there anything that 
the existing os.path *won't do* that we desperately need it to do?

3) Assuming that the answer to #1 is "yes", the next question is: 
"evolution or revolution?" Do we want something that looks 95%, 80%, or 
0% the same as the existing library? Is this just a case of moving 
around a few stray functions, or is are we going to take and axe and 
give os.path a reprogramming job it will never forget?

4) My third question is: Who are we going to steal our ideas from? 
Boost, Java, C# and others - all are worthy of being the, ahem, target 
of our inspiration. Or we have some alternative that's so cool that it 
makes sense to "Think Different(ly)"?

5) Must there be one ring to rule them all? I suggested earlier that we 
might have a "low-level" and a "high-level" API, one built on top of the 
other. Is this a good idea, or a non-starter?

OK lets start with that and see what happens.

-- Talin