[Python-3000] Mini Path object

[Greg Ewing]

Talin wrote:

> I'm a little confused here about the model of how platform-specific and 
> application-specific formats are represented. Is it the case that the 
> creation function converts the platform-specific path into a generic, 
> universal path object, or does it create a platform-specific path object?

I don't think it makes sense to mix different platform's
path objects at all. They're not just different ways of
representing the same thing, they're actually different
things.

I would drop any notion of format specifiers when
constructing or joining paths. If you really want to do
something like that, you can split it into components and
construct a new path object of a different type from those
components. And then it's up to you to deal with whatever
problems arise, e.g. how to get a Windows drive letter into
a Unix path object.

> The whole issue of path simplification is really an "end user debugging" 
> issue. Since simplified and non-simplified paths are equivalent

Actually, they're not -- it's possible for simplified and
non-simplified versions of the same path to refer to different
filesystem objects. So I'd say that the path object should
never try to simplify on its own initiative, except in ways
that can't possibly alter the semantics of the path.

>>>>    .abspath()
>>>
>>>I've always thought this was a strange function. To be honest, I'd
>>>rather explicitly pass in the cwd().
>>
>>I use it; it's convenient.  The method name could be improved.

It does violate the constraint of the path object being
restricted to path algebra operations, though, since the
result depends on the cwd of the process.

>>Perhaps.  There was one guy in the discussion about Noam's path module
>>who didn't like .expand() at all; he thought it did too many things
>>implicitly and was thus too magical.

And again, it strays outside the domain of path algebra
operations.

>>>Do we need to somehow unify the concept of 'drive' and 'unc' part? Maybe
>>>'.device' could return the part before the first directory name.

These sound like they belong in the realm of extensions
belonging to platform-specific path subclasses.

> A directory name with a '.' in it isn't really an extension, at least 
> not as interpreted by most filesystems. For example, if you create a 
> folder in MSWindows, and name it "foo.bar" and then look at it in 
> windows explorer, it will still say it's a folder; It won't try and 
> display it as a "folder of type 'bar'".

Not true on MacOSX, where some kinds of directories
do indeed have meaningful extensions -- eg. .app,
.framework.

> In any case, I really don't think we need to support any special 
> accessors for accessing the part after the '.' in any component but the 
> last.

That's probably true.

--
Greg