[Python-3000] Mini Path object

[Greg Ewing]

Talin wrote:

> I think that there's a reasonable chance of acceptance for an object 
> that does filesystem-like operations that *doesn't overlap* with what 
> the Path object does. But what you are proposing is a *superset* of what 
> Path does (because you're saying its a subclass), and I don't think that 
> will go over well.

I agree. File system operations should be functions that
operate on paths, not methods of a special kind of path.

> Mike Orr wrote:

>>I like the syntax of a join method.  With a multi-arg constructor it's
>>not necessary though.

True, but seeing as we're talking about an algebra, it
would be nice to have some operators for the most
frequent operations. Perhaps

    p1 / p2     #  combine paths
    p & ext     #  add extension
    p | ext     #  replace last extension
    p | ""      #  remove last extension

>>But what harm is there in making them scalable to multiple extensions?
>>
>>    .add_exts(*exts)
>>    .del_exts(N)
>>    .replace_exts(N, *exts)

Not sure if this is worth it, since even when a
file has multiple extensions, you're usually dealing
with them one at a time. E.g. given foo.tar.gz, you
first ungzip it to give foo.tar, and then untar it
to give foo (conceptually, at least).

> Someone in another message pointed out that paths, being based on 
> strings, are immutable, so this whole handling of extensions will have 
> to be done another way.

The relevant methods would just have to return new
paths instead of modifying in-place.

--
Greg