[Python-ideas] PEP 428: poll about the joining syntax

[Nick Coghlan]

On Sat, Oct 13, 2012 at 2:27 AM, Ethan Furman <ethan at stoneleaf.us> wrote:
> Georg Brandl wrote:
>>
>> Am 12.10.2012 14:45, schrieb Blake Hyde:
>>>
>>> I'm a Python developer rather than a developer of Python, but I'd like to
>>> ask a
>>> question about this option (and implicitly vote against it, I suppose);
>>> if you
>>> specialize a method name, such as .pathjoin, aren't you implying that
>>> methods
>>> must be unambiguous even across types and classes?  This seems negative.
>>> Even
>>> if .join is already used for strings, it also makes sense for this use
>>> case.
>>
>>
>> Of course different classes can have methods of the same name.
>>
>> The issue here is that due to the similarity (and interchangeability) of
>> path
>> objects and strings it is likely that people get them mixed up every now
>> and
>> then, and if .join() works on both objects the failure mode (strange
>> result
>> from str.join when you expected path.join) is horribly confusing.
>
>
> I don't understand the "horribly confusing" part.  Sure, when I got them
> mixed up and ended up with a plain ol' string instead of a really cool Path
> it took a moment to figure out where I had made the error, but the traceback
> of "AttributeError: 'str' object has no attribute 'path'" left absolutely no
> room for confusion as to what the problem was.

Now, instead of retrieving an attribute, call str() and send the path
name over a pipe or socket, or save it to a file. Instead of an
immediate error, you'll get a bad path somewhere *else*, and have to
track down where the data corruption came from (which not even be in
the current process, or in a process that was even running on the
current machine).

Making "+" and "Path.join" mean something different from what they
mean when called on strings is, in the specific case of a path
representation, far too likely to lead to data corruption bugs for us
to be happy with allowing it in the standard library. This is one I
think Jason Orendorff's original path.py got right, which is why my
current preference is "just copy path.py and use / and Path.joinpath".

Cheers,
Nick.

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