[Python-ideas] PEP 428 - object-oriented filesystem paths
p.f.moore at gmail.com
Mon Oct 8 13:11:52 CEST 2012
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. 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
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.
+1 on a method
-1 on subpath as its name
+0 on join as its name
I'm happy for someone to come up with a better name
-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.
More information about the Python-ideas