[Python-ideas] PEP 428 - object-oriented filesystem paths

[Steven D'Aprano]

On 08/10/12 21:31, Nick Coghlan wrote:
> I've said before that I like the general shape of the pathlib API and
> that's still the case. It's the only OO API I've seen that's
> semantically clean enough for me to support introducing it as "the"
> standard path abstraction in the standard library.

The use of indexing to join path components:

     # Example from the PEP
     >>> p = PurePosixPath('foo')
     >>> p['bar']
     PurePosixPath('foo/bar')

is an absolute deal breaker for me. I'd rather stick with the status quo
than have to deal with something which so clearly shouts "index/key lookup"
but does something radically different (join/concatenate components).

I would *much* rather use the / or + operator, but I think even better
(and less likely to cause arguments about the operator) is an explicit
`join` method. After all, we call it "joining path components", so the name
is intuitive (at least for English speakers) and simple.

I don't believe that there will be confusion with str.join -- we already
have an os.path.join method, and I haven't seen any sign of confusion
caused by that.


[...]
> It's important to remember that you can't readily search for syntactic
> characters or common method names to find out what they mean, and
> these days that kind of thing should be taken into account when
> designing an API.

To some degree, that's a failure of the search engine, not of the
language. Why can't we type "symbol=+" into the search field and
get information about addition? If Google can let you do mathematical
calculations in their search field, surely we could search for symbols?
But I digress.


>"p.subpath('foo', 'bar')" looks like executable
> pseudocode for creating a new path based on existing one to me,

That notation quite possibly goes beyond unintuitive to downright
perverse. You are using a method called "subpath" to generate a
*superpath* (deeper, longer path which includes p as a part).

http://en.wiktionary.org/wiki/subpath

Given:
p = /a/b/c
q = /a/b/c/d/e  # p.subpath(d, e)

p is a subpath of q, not the other way around: q is a path PLUS some
subdirectories of that path, i.e. a longer path.

It's also a pretty unusual term outside of graph theory: Googling finds
fewer than 400,000 references to "subpath". It gets used in graphics
applications, some games, and in an extension to mercurial for adding
symbolic names to repo URLs. I can't see any sign that it is used in
the sense you intend.


> unlike
> "p / 'foo' / 'bar'", "p['foo', 'bar']", or "p.join('foo', 'bar')".

Okay, I'll grant you that we'll probably never get a consensus on
operators + versus / but I really don't understand why you think that
p.join is unsuitable for a method which joins path components.



-- 
Steven