<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 6, 2014 at 10:47 AM, Barry Warsaw <span dir="ltr"><<a href="mailto:barry@python.org" target="_blank">barry@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Over in issue 22570, I lament the fact that while pathlib is awesome, its<br>
wider support in the stdlib is pretty sparse.  I've tried to convert parts of<br>
a medium sized Python 3 application from os.path to pathlib and found this<br>
lack of support rather demotivating.  Yes, it's fairly easy to wrap Path<br>
objects in str() to pass them to stdlib methods that expect only strings, but<br>
it's a lot of work in user code and I find that the resulting str()s are<br>
distracting.  It's a disincentive.<br>
<br>
Antoine provided a link to a previous discussion[*] but that didn't go very<br>
far.<br>
<br>
One simple solution would be to sprinkle str() calls in various stdlib<br>
methods, but I'm not sure if that would fail miserably in the face of bytes<br>
paths (if the original stdlib API even accepts bytes paths).  The suggestion<br>
in the issue is to add a "path protocol" and the referenced article suggests<br>
.strpath and .bytespath.  OTOH, isn't str() and bytes() enough?<br>
<br>
I don't have any other brilliant ideas, but I opened the issue and am posting<br>
here to see if we can jump start another discussion for Python 3.5.  I'd<br>
*like* to use more Paths, but not at the expense of my own code's readability.<br>
Yes, I'd sacrifice a bit of readability in the stdlib, especially if that<br>
would cover more use cases.<br>
<br>
Cheers,<br>
-Barry<br>
<br>
[*] <a href="https://mail.python.org/pipermail/python-ideas/2014-May/027869.html" target="_blank">https://mail.python.org/pipermail/python-ideas/2014-May/027869.html</a><br clear="all"></blockquote><br>I'd turn it around.<br><br>You can construct a Path from an argument that can be either a string or another Path. Example:<br><br>>>> from pathlib import Path<br>>>> p = Path('/etc/passwd')<br>>>> q = Path(p)<br>>>> p == q<br></div><div class="gmail_quote">True<br>>>> <br></div><div class="gmail_quote"><br>So you could start refactoring stdlib code to use Path internally without forcing the callers to use Path, but still *allow* the callers to pass a Path. Though I'm not sure how this would work for return values without breaking backwards compatibility -- you'd have to keep returning strings and the callers would have to use the same mechanism to go back to using Paths.<br></div><br>-- <br>--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)
</div></div>