<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, 6 Apr 2016 at 11:06 Ethan Furman <<a href="mailto:ethan@stoneleaf.us">ethan@stoneleaf.us</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 04/06/2016 10:26 AM, Brett Cannon wrote:<br>
<br>
> WIth Ethan volunteering to do the work to help make a path protocol a<br>
> thing -- and I'm willing to help along with propagating this through the<br>
> stdlib where I think Serhiy might be interested in helping as well --<br>
> and a seeming consensus this is a good idea, it seems like this proposal<br>
> has a chance of actually coming to fruition.<br>
<br>
Excellent! Let's proceed along this path ;) until somebody objects.<br>
<br>
<br>
> Now we need clear details. :) Some open questions are:<br>
><br>
> 1. Name: __path__, __fspath__, or something else?<br>
<br>
__fspath__<br></blockquote><div><br></div><div>+1 for __path__, +0 for __fspath__ (I don't know how widespread the notion that "fs" means "file system" is).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
> 2. Method or attribute? (changes what kind of one-liner you might use<br>
> in libraries, but I think historically all protocols have been<br>
> methods and the serialized string representation might be costly to<br>
> build)<br>
<br>
I would prefer an attribute, but yeah I think dunders are typically<br>
methods, and I don't see this being special enough to not follow that trend.<br></blockquote><div><br></div><div>Depends on what we want to tell 3rd-party libraries to do to support pathlib if they are on 3.3 or if they are worried about people using Python 3.4.2 or 3.5.1. An attribute still works with `getattr(path, '__path__', path)`. But with a method you probably want either `path.__path__() if hasattr(path, '__path__') else path` or `getattr(path, '__path__', lambda: path)()`.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
> 3. Built-in? (name is dependent on #1 if we add one)<br>
<br>
fspath() -- and it would be handy to have a function that return either<br>
the __fspath__ results, or the string (if it was one), or raise an<br>
exception if neither of the above work out.<br></blockquote><div><br></div><div>So:</div><div><br></div><div> # Attribute</div><div> def fspath(path):</div><div> hasattr(path, '__path__'):</div><div> return path.__path__</div><div> if isinstance(path, str):</div><div> return path</div><div> raise NotImplementedError # Or TypeError?</div><div> </div><div> # Method</div><div> def fspath(path):</div><div> try:</div><div> return path.__path__()</div><div> except AttributeError:</div><div> if isinstance(path, str):</div><div> return path</div><div> raise TypeError # Or NotImplementedError?</div><div><br></div><div>Or you can drop the isinstance() check and simply check for the attribute/method and use it and otherwise return `path` and let the code's duck-typing of str handle catching an unexpected type for a path. At which point the built-in becomes whatever idiom we promote for pathlib usage that pre-dates this protocol.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
> 4. Add the method/attribute to str? (I assume so, much like __index__()<br>
> is on int, but I have not seen it explicitly stated so I would<br>
> rather clarify it)<br>
<br>
I don't think that's needed. With Path() and fspath() it's trivial to<br>
make sure one has what one wants.<br></blockquote><div><br></div><div>If we add str.__fspath__ then the function becomes:</div><div><br></div><div> def fspath(path):</div><div> return path.__fspath__()</div><div><br></div><div>Which might be too simplistic for a built-in, but that also means adding it on str would potentially negate the need for a built-in.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
> 5. Expand the C API to have something like PyObject_Path()?<br>
<br>
No opinion.<br></blockquote><div><br></div><div>If we add a built-in then I say we add an equivalent function in the C API.</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">
<br>
<br>
> Some people have asked for the pathlib PEP to have a more flushed out<br>
> reasoning as to why pathlib doesn't inherit from str. If Antoine doesn't<br>
> want to do it I can try to instil my blog post into a more succinct<br>
> paragraph or two and update the PEP myself.<br>
<br>
Nice.<br>
<br>
<br>
> Is this going to require a PEP or if we can agree on the points here are<br>
> we just going to do it? If we think it requires a PEP I'm willing to<br>
> write it, but I obviously have no issue if we skip that step either. :)<br>
<br>
If there are no (serious?) objects I don't think a PEP is needed.<br>
<br>
<br>
> Oh, and we should resolve this before the next release of Python 3.4,<br>
> 3.5, or 3.6 so that pathlib can be updated in those releases.<br>
<br>
Agreed.<br>
<br>
--<br>
~Ethan~<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" 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/brett%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/brett%40python.org</a><br>
</blockquote></div></div>