p + q               +1<br><br>This is a familiar notation to any developer and its been used widely.<br><br>Regards,<br>Rohit.<br><br><div class="gmail_quote">On Thu, Oct 11, 2012 at 8:04 AM, Eric Snow <span dir="ltr"><<a href="mailto:ericsnowcurrently@gmail.com" target="_blank">ericsnowcurrently@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p><br>
On Oct 8, 2012 5:35 PM, "Eric Snow" <<a href="mailto:ericsnowcurrently@gmail.com" target="_blank">ericsnowcurrently@gmail.com</a>> wrote:<br>
><br>
> On Mon, Oct 8, 2012 at 12:47 PM, Antoine Pitrou <<a href="mailto:solipsis@pitrou.net" target="_blank">solipsis@pitrou.net</a>> wrote:<br>
> > - `p[q]` joins path q to path p<br>
> -1<br>
> > - `p + q` joins path q to path p<br>
> -1<br>
> > - `p / q` joins path q to path p<br>
> -1<br>
> > - `p.join(q)` joins path q to path p<br>
> +1 (with a different name)<br>
><br>
> I've found Nick's argument against operators-from-day-1 to be<br>
> convincing, as well as his argument against join() or any other name<br>
> already provided by string/sequence APIs.</p>
<p>Changing my vote:</p>
<p>p[q]                 -1<br>
p + q               -1<br>
p / q               +0<br>
p.pathjoin()   +1</p>
<p>A method is essential, regardless of the color the bikeshed ends up.  As far as operators go, / is the only option here that doesn't conflict with string/collection APIs.  The alternative has an adverse impact on subclassing and on future design choices on the path API.  This goes for the method name too.</p>
<span class="HOEnZb"><font color="#888888">

<p>-eric<br>
</p>
</font></span><br>_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-ideas" target="_blank">http://mail.python.org/mailman/listinfo/python-ideas</a><br>
<br></blockquote></div><br>