[Python-ideas] Better stdlib support for Path objects

[Donald Stufft]

> On Oct 6, 2014, at 1:47 PM, Barry Warsaw <barry at python.org> wrote:
> 
> Over in issue 22570, I lament the fact that while pathlib is awesome, its
> wider support in the stdlib is pretty sparse.  I've tried to convert parts of
> a medium sized Python 3 application from os.path to pathlib and found this
> lack of support rather demotivating.  Yes, it's fairly easy to wrap Path
> objects in str() to pass them to stdlib methods that expect only strings, but
> it's a lot of work in user code and I find that the resulting str()s are
> distracting.  It's a disincentive.
> 
> Antoine provided a link to a previous discussion[*] but that didn't go very
> far.
> 
> One simple solution would be to sprinkle str() calls in various stdlib
> methods, but I'm not sure if that would fail miserably in the face of bytes
> paths (if the original stdlib API even accepts bytes paths).  The suggestion
> in the issue is to add a "path protocol" and the referenced article suggests
> .strpath and .bytespath.  OTOH, isn't str() and bytes() enough?
> 
> I don't have any other brilliant ideas, but I opened the issue and am posting
> here to see if we can jump start another discussion for Python 3.5.  I'd
> *like* to use more Paths, but not at the expense of my own code's readability.
> Yes, I'd sacrifice a bit of readability in the stdlib, especially if that
> would cover more use cases.
> 
> 

Suggested by Alex on IRC:

Path(“…”).path instead of str(Path(“…”)). Tiny change but it’s a bit easier to type?

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA