<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, 6 Apr 2016 at 14:03 Wes Turner <<a href="mailto:wes.turner@gmail.com">wes.turner@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr"><br>
On Apr 6, 2016 12:47 PM, "Brett Cannon" <<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>> wrote:<br>
><br>
><br>
><br>
> On Wed, 6 Apr 2016 at 10:41 Wes Turner <<a href="mailto:wes.turner@gmail.com" target="_blank">wes.turner@gmail.com</a>> wrote:<br>
>><br>
>> * +1 for __path__, __fspath__<br>
>> (though I don't know what each does)<br>
><br>
><br>
> Returns a string representing a file system path.</p>
<p dir="ltr">Why two methods? __uripath__?</p>
<p dir="ltr"> (scheme, host (port), path, query, fragment) so, not __uripath__</p>
<p dir="ltr">what would be the difference between __path__ and __fspath__?</p></blockquote><div><br></div><div>There is no difference; we're trying to choose a name.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr"> </p>
<p dir="ltr">> <br>
>><br>
>> * why not Text(basestring / bytestring) and pathlib.Path(Text)?<br>
><br>
><br>
> See the points about next() vs __next__()</p>
<p dir="ltr">Path(b'123') / u'456'</p>
<p dir="ltr">similarly,<br>
Path(b'123') / UTF8 / UTF16</p></blockquote><div><br></div><div>As other people pointed out on the other thread, while bytes paths do exist, we don't want to promote them as they are a mess to work with.</div><div><br></div><div>-Brett</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">> <br>
>><br>
>> * are there examples of cases where this cannot be?<br>
><br>
><br>
> I don't understand what you think "cannot be".</p>
<p dir="ltr">What one recommends (path.py(str) / str(pathlib.Path()) + getattr) is distinct from what any given programmer chooses to do with their code.</p>
<p dir="ltr">> <br>
>><br>
>> * if not, +1 for subclassing str/Text<br>
>><br>
>> * where are the examples of method collisions between the str interface and the pathlib.Path interface?<br>
><br>
><br>
> There aren't any and that's partially why some people wanted the str subclass to begin with.<br>
><br>
> Please consider this thread a str-subclass-free zone. This line of discussion is to flesh out the proposal for a path protocol as a proposal against subclassing str, not to settle the whole discussion outright. If you want to continue to debate the subclassing-str side of this please use the other thread.</p>
<p dir="ltr">this seems to be a sudden, arbitrary distinction.</p>
<p dir="ltr">are these proposals necessarily disjoint?</p>
<p dir="ltr">so,<br>
adding getattr(path, '__path__', path) to stdlib and other code is going to prevent which edge cases (before os.path.normpath()* anyway) for which benefit?</p>
<p dir="ltr">when do I do getattr(path, '__fspath__', path)?</p>
<p dir="ltr">><br>
> -Brett<br>
> <br>
>><br>
>> * str.__div__ is nonsensical<br>
>> * pathlib.Path.__div__ is super-useful</p>
<p dir="ltr">ah, not .__add__() but .append()</p>
<p dir="ltr">I suppose the request here is for the cases which would be prevented (that we need to learn to look for)</p>
<p dir="ltr">>><br>
>> <br>
>><br>
>> On Apr 6, 2016 10:10 AM, "Ethan Furman" <<a href="mailto:ethan@stoneleaf.us" target="_blank">ethan@stoneleaf.us</a>> wrote:<br>
>>><br>
>>> On 04/05/2016 11:57 PM, Nick Coghlan wrote:<br>
>>>><br>
>>>> On 6 April 2016 at 16:53, Nathaniel Smith <<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>> wrote:<br>
>>>>><br>
>>>>> 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>
>>><br>
>>><br>
>>>>>> I'd missed the existing precedent in DirEntry.path, so simply taking<br>
>>>>>> that and running with it sounds good to me.<br>
>>>>><br>
>>>>><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>
>>>><br>
>>>><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>
>>><br>
>>><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" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
>>><br>
>>> Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com" target="_blank">https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com</a><br>
>><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" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
>> Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/brett%40python.org" target="_blank">https://mail.python.org/mailman/options/python-dev/brett%40python.org</a><br>
</p>
</blockquote></div></div>