[Python-ideas] Better stdlib support for Path objects

[Georg Brandl]

On 10/07/2014 04:59 PM, Stephen J. Turnbull 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.

That's exactly what I'd be worried about.  It would require a big effort
to convert enough APIs to make the few that don't take Paths insignificant.
That would also signal a strong urge to third-party libs to become Path-aware.
However, I'm skeptical that python-dev can muster enough energy for this
effort.

I believe that a .path attribute (name to be discussed) is probably as good
as we can do.

In reverse, it means that Path should grow many utility methods for common
operations.

> 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.

Note that Barry said: "I wouldn't expect low level APIs like os.path and
built-in open to accept Path objects." which refers to open(), not os.open().

Georg