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
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
