[Python-ideas] Better stdlib support for Path objects

[Donald Stufft]

> On Oct 7, 2014, at 9:25 AM, random832 at fastmail.us wrote:
> 
> On Tue, Oct 7, 2014, at 09:20, Donald Stufft wrote:
>>> On Oct 7, 2014, at 9:17 AM, Barry Warsaw <barry at python.org> wrote:
>>> On Oct 07, 2014, at 07:54 PM, Nick Coghlan wrote:
>>>> A single dispatch generic function as an adapter API would be another
>>>> option, but would likely pose bootstrapping problems for the lowest level
>>>> interfaces like os.path and the open builtin.
>>> 
>>> I wouldn't expect low level APIs like os.path and built-in open to accept Path
>>> objects.  pathlib already covers most of those use cases, and whatever is
>>> missing from there can probably be easily added.   It's higher level libraries
>>> accepting Path objects that is more interesting I think.
>> 
>> TBH I find a path library that I can’t use anywhere I use paths to be
>> rather neutered.
> 
> 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.

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