<p dir="ltr">* +1 for __path__, __fspath__<br>
(though I don't know what each does)</p>
<p dir="ltr">* why not Text(basestring / bytestring) and pathlib.Path(Text)?<br>
* are there examples of cases where this cannot be?<br>
* if not, +1 for subclassing str/Text</p>
<p dir="ltr"> * where are the examples of method collisions between the str interface and the pathlib.Path interface?<br>
* str.__div__ is nonsensical<br>
* pathlib.Path.__div__ is super-useful</p>
<p dir="ltr"> </p>
<div class="gmail_quote">On Apr 6, 2016 10:10 AM, "Ethan Furman" <<a href="mailto:ethan@stoneleaf.us">ethan@stoneleaf.us</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 04/05/2016 11:57 PM, Nick Coghlan wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 6 April 2016 at 16:53, Nathaniel Smith <<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Apr 5, 2016 at 11:29 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> wrote:<br>
</blockquote></blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'd missed the existing precedent in DirEntry.path, so simply taking<br>
that and running with it sounds good to me.<br>
</blockquote>
<br>
This makes me twitch slightly, because NumPy has had a whole set of<br>
problems due to the ancient and minimally-considered decision to<br>
assume a bunch of ad hoc non-namespaced method names fulfilled some<br>
protocol -- like all .sum methods will have a signature that's<br>
compatible with numpy's, and if an object has a .log method then<br>
surely that computes the logarithm (what else in computing could "log"<br>
possibly refer to?), etc. This experience may or may not be relevant,<br>
I'm not sure -- sometimes these kinds of twitches are good guides to<br>
intuition, and sometimes they are just knee-jerk responses to an old<br>
and irrelevant problem :-)<br>
<br>
But you might want to at least think about<br>
how common it might be to have existing objects with unrelated<br>
attributes that happen to be called "path", and the bizarro problems<br>
that might be caused if someone accidentally passes one of them to a<br>
function that expects all .path attributes to be instances of this new<br>
protocol.<br>
</blockquote>
<br>
sys.path, for example.<br>
<br>
That's why I'd actually prefer the implicit conversion protocol to be<br>
the more explicitly named "__fspath__", with suitable "__fspath__ =<br>
path" assignments added to DirEntry and pathlib. However, I'm also not<br>
offering to actually *do* the work here, and the casting vote goes to<br>
the folks pursuing the implementation effort.<br>
</blockquote>
<br>
If we decide upon __fspath__ (or __path__) I will do the work on pathlib and scandir to add those attributes.<br>
<br>
--<br>
~Ethan~<br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com" rel="noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com</a><br>
</blockquote></div>