On 12 October 2012 20:39, Georg Brandl <span dir="ltr"><<a href="mailto:g.brandl@gmx.net" target="_blank">g.brandl@gmx.net</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Am 12.10.2012 18:27, schrieb Ethan Furman:<br>
<div class="im">> Georg Brandl wrote:<br>
>> Am 12.10.2012 14:45, schrieb Blake Hyde:<br>
>>> I'm a Python developer rather than a developer of Python, but I'd like to ask a<br>
>>> question about this option (and implicitly vote against it, I suppose); if you<br>
>>> specialize a method name, such as .pathjoin, aren't you implying that methods<br>
>>> must be unambiguous even across types and classes?  This seems negative.  Even<br>
>>> if .join is already used for strings, it also makes sense for this use case.<br>
>><br>
>> Of course different classes can have methods of the same name.<br>
>><br>
>> The issue here is that due to the similarity (and interchangeability) of path<br>
>> objects and strings it is likely that people get them mixed up every now and<br>
>> then, and if .join() works on both objects the failure mode (strange result<br>
>> from str.join when you expected path.join) is horribly confusing.<br>
><br>
> I don't understand the "horribly confusing" part.  Sure, when I got them<br>
> mixed up and ended up with a plain ol' string instead of a really cool<br>
> Path it took a moment to figure out where I had made the error, but the<br>
> traceback of "AttributeError: 'str' object has no attribute 'path'" left<br>
> absolutely no room for confusion as to what the problem was.<br>
<br>
</div>"no attribute 'path'"?  Not sure where that exception comes from.<br>
This is what I meant:<br>
<br>
>>> p = Path('/usr')<br>
>>> p.join('lib')<br>
Path('/usr/lib')<br>
<br>
>>> p = '/usr'<br>
>>> p.join('lib')<br>
'l/usri/usrb'<br></blockquote><div><br></div><div>I don't know about you, but I found that so horribly confusing I had to check the output. I'm just not used to thinking of str.join(str) as sensible, and I could not for the life of me see where the output 'l/usri/usrb' came from. Where was "lib"?</div>

<div><br></div><div>I might just have been an idiot for a minute, but it'll just get harder in real code. And I'm not the worst for stupid mistakes: we wan't newbies to be able (and want) to use the built in path modules. When they come back wondering why </div>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><font face="courier new, monospace">homepath.join("joshua").join(".config")</font></blockquote>

returned<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><font face="courier new, monospace">'.j/homeo/homes/homeh/homeu/homeacj/homeo/homes/homeh/homeu/homeaoj/homeo/homes/homeh/homeu/homeanj/homeo/homes/homeh/homeu/homeafj/homeo/homes/homeh/homeu/homeaij/homeo/homes/homeh/homeu/homeag'</font></blockquote>

<div>we are going to have a problem.</div><div><br></div><div>So I agree with you [Georg Brandl] here. I would even rather .pathjoin/.joinpath than .join despite the utterly painful name*.</div><div><br></div><div>* As others have stated, if you like it why not .strjoin and .dictupdate and .listappend?</div>

</div>