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

[Guido van Rossum]

On Mon, Oct 8, 2012 at 11:56 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Tue, 9 Oct 2012 00:19:03 +0530
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>> >
>> > The join() method already exists in the current PEP, but it's less
>> > convenient, synctatically, than either '[]' or '/'.
>>
>> Right. My objections boil down to:
>>
>> 1. The case has not been adequately made that a second way to do it is
>> needed. Therefore, the initial version should just include the method
>> API.
>
> But you really want a short method name, otherwise it's better to have
> a dedicated operator.  joinpath() definitely doesn't cut it, IMO.

Maybe you're overreacting? The current notation for this operation is
os.path.join(p, q) which is even longer than p.pathjoin(q). To me the
latter is fine.

> (perhaps that's the same reason I am reluctant to use str.format() :-))
>
> By the way, I also thought of using __call__, but for some reason I
> think it tastes a bit bad ("too clever"?).

__call__ overloading is often overused. Please don't go there. It is
really hard to figure out what some (semi-)obscure operation means if
it uses __call__ overloading.

>> 2. Using "join" as the method name is a bad idea for the same reason
>> that using "+" as the operator syntax would be a bad idea: it can
>> cause erroneous output instead of an exception if a string is passed
>> where a Path object is expected.
>
> Admitted, although I think the potential for confusion is smaller
> than with "+" (I can't really articulate why, it's just that I fear
> one much less than the other :-)).

Personally I fear '+' much more -- to me, + can be used to add an
extension without adding a new directory level. If we *have* to
overload an operator, I'd prefer p/q over p[q] any day.

-- 
--Guido van Rossum (python.org/~guido)