<p dir="ltr"></p>
<p dir="ltr">--<br>
Ryan<br>
[ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong.<br>
<a href="http://kirbyfan64.github.io/">http://kirbyfan64.github.io/</a><br>
On Apr 6, 2016 12:28 PM, "Brett Cannon" <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:<br>
><br>
> WIth Ethan volunteering to do the work to help make a path protocol a thing -- and I'm willing to help along with propagating this through the stdlib where I think Serhiy might be interested in helping as well -- and a seeming consensus this is a good idea, it seems like this proposal has a chance of actually coming to fruition.<br>
><br>
> Now we need clear details. :) Some open questions are:</p>
<p dir="ltr">My votes:</p>
<p dir="ltr">> Name: __path__, __fspath__, or something else?</p>
<p dir="ltr">__path__. Considering everything related to `pathlib` uses the word `path`, __fspath__ seems kind of odd.</p>
<p dir="ltr">> Method or attribute? (changes what kind of one-liner you might use in libraries, but I think historically all protocols have been methods and the serialized string representation might be costly to build)</p>
<p dir="ltr">Method. Using an attribute would be needlessly inconsistent.</p>
<p dir="ltr">> Built-in? (name is dependent on #1 if we add one)<br>
> Add the method/attribute to str? (I assume so, much like __index__() is on int, but I have not seen it explicitly stated so I would rather clarify it)</p>
<p dir="ltr">I agree; this would avoid lots of excess complexity.</p>
<p dir="ltr">> Expand the C API to have something like PyObject_Path()?</p>
<p dir="ltr">-1. PyFileObject was already removed from Python 3; it seems useless to add another one.</p>
<p dir="ltr">><br>
> Some people have asked for the pathlib PEP to have a more flushed out reasoning as to why pathlib doesn't inherit from str. If Antoine doesn't want to do it I can try to instil my blog post into a more succinct paragraph or two and update the PEP myself.<br>
><br>
> Is this going to require a PEP or if we can agree on the points here are we just going to do it? If we think it requires a PEP I'm willing to write it, but I obviously have no issue if we skip that step either. :)<br>
><br>
> Oh, and we should resolve this before the next release of Python 3.4, 3.5, or 3.6 so that pathlib can be updated in those releases.<br>
><br>
> -Brett<br>
><br>
><br>
> On Wed, 6 Apr 2016 at 08:09 Ethan Furman <<a href="mailto:ethan@stoneleaf.us">ethan@stoneleaf.us</a>> wrote:<br>
>><br>
>> On 04/05/2016 11:57 PM, Nick Coghlan wrote:<br>
>> > On 6 April 2016 at 16:53, Nathaniel Smith <<a href="mailto:njs@pobox.com">njs@pobox.com</a>> wrote:<br>
>> >> On Tue, Apr 5, 2016 at 11:29 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<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>
>> >> 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>
>> > 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>
>> If we decide upon __fspath__ (or __path__) I will do the work on pathlib<br>
>> and scandir to add those attributes. <br>
><br>
><br>
> _______________________________________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-dev">https://mail.python.org/mailman/listinfo/python-dev</a><br>
> Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com">https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com</a><br>
><br>
</p>