On Mon, Oct 8, 2012 at 4:41 PM, Paul Moore
On 8 October 2012 11:31, Nick Coghlan
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@gmail.com | Brisbane, Australia