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

[Nick Coghlan]

On Mon, Oct 8, 2012 at 4:41 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 8 October 2012 11:31, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> 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. "p.subpath('foo', 'bar')" looks like executable
>> pseudocode for creating a new path based on existing one to me, unlike
>> "p / 'foo' / 'bar'", "p['foo', 'bar']", or "p.join('foo', 'bar')".
>
> Until precisely this point in your email, I'd been completely
> confused, because I thought that p.supbath(xxx) was some sort of "is
> xxx a subpath of p" query.

That's OK, I don't set the bar for my mnemonics *that* high: I use
Guido's rule that good names are easy to remember once you know what
they mean. Being able to guess precisely just from the name is a nice
bonus, but not strictly necessary.

> It never occurred to me that it was the
> os.path.join equivalent operation. In fact, I'm not sure where you got
> it from, as I couldn't find it in either the PEP or in pathlib's
> documentation.

I made it up by using "make subpath" as the reverse of "get relative
path".  The "is subpath" query could be handled by calling
"b.startswith(a)".

I'd be fine with "joinpath" as well (that is what path.py uses to
avoid the conflict with str.join)

> I'm not unhappy with using a method for creating a new path based on
> an existing one (none of the operator forms seems particularly
> compelling to me) but I really don't like subpath as a name.
>
> I don't dislike p.join(parts) as it links back nicely to os.path.join.
> I can't honestly see anyone getting confused in practice. But I'm not
> so convinced that I would want to insist on it.

I really don't like it because of the semantic conflict with str.join.
That semantic conflict is the reason I only do "from os.path import
join as joinpath" or else call it as "os.path.join" - I find that
using the bare "join" directly is too hard to interpret when reading
code.

I consider .append() and .extend() unacceptable for the same reason -
they're too closely tied to mutating method semantics on sequences.

> -0 on a convenience operator form. Mainly because "only one way to do
> it" and the general controversy over which is the best operator to
> use, suggests that leaving the operator form out altogether at least
> in the initial implementation is the better option.

Right, this is my main point as well. The method form *has* to exist.
I am *not* convinced that the cute syntactic shorthands actually
*improve* readability - they improve *brevity*, but that's not the
same thing.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia