[Python-ideas] Better stdlib support for Path objects

[Donald Stufft]

> On Oct 7, 2014, at 10:59 AM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> 
> Donald Stufft writes:
>>> On Oct 7, 2014, at 9:25 AM, random832 at fastmail.us wrote:
> 
>>> It makes about as much sense for os.open to accept a path as it would
>>> for it to return a TextIOWrapper instead of an int. The same applies, in
>>> reverse, to built-in open.
>> 
>> I might agree with you if there wasn’t 20 years of code that
>> expects to be able to pass a “path” in to various places. Having to
>> keep a mental note, or worse look up in the documentation every
>> time, where I’m expected to pass a Path object and where I’m
>> expected to pass a str is just about the worst UX I can imagine.
> 
> You wouldn't need a mental memo.  Just do "import os" rather than
> "from os import *" and the "os." prefix will tell you you need a str.
> Otherwise use a Path.
> 
> That would be the goal, I expect.  How to get there, I'm not sure.

I never use star imports.

The problem is that not only does tons of stuff in the stdlib currently accept
only str, but so do tons of things on PyPI. Without looking at the
implementation/docs for each one of these items I won’t know if I can pass it a
str or a Path (or more likely I won’t know if I need to coerce my Path to a str
since i doubt anyone is going to make Path only APIs).

For me personally this means that pathlib will likely never be a useful tool
because I find the need to coerce all over the place far worse than using the
relevant os.path functions.

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