[Python-ideas] Working with Path objects: p-strings?

[Andrew Barnert]

On Mar 25, 2016, at 13:20, Koos Zevenhoven <k7hoven at gmail.com> wrote:
> 
> So, let's start a new thread about how to deal with pathlib.Path
> objects, involving how/whether to convert between str and Path

As a different point:

If we _don't_ either subclass str or find some way to make things magically work, is there any other way to start getting more uptake on pathlib? This may only be anecdotal, but from what I can tell, nobody is using it, because everyone who tries is put off by the need to convert back and forth everywhere.

Last year, everyone agreed that it would be good if at least the stdlib accepted paths everywhere, which might prompt third party libs to start doing the same. But nobody's started writing patches to do that. And I'm not sure we'd want it to happen in an uncoordinated way anyway, since there are at least four different ways to do it, and if we pick among them arbitrarily for different parts of the stdlib, we'll have a huge mess, and possibly behavioral inconsistencies.

The four ways I can think of are (in every function that currently takes a "path: str" argument, and should now take a "path: str | Path"):

 * path = str(path)
 * path = Path(path)
 * if isinstance(path, Path): ... else: ...
 * try: f = path.open('w') except AttributeError: open(path, 'w')

It's also worth noting that all but the first require every module to depend on Path. Including C modules. And modules in the bootstrap. But the first version makes a bad guide for third-party code, because a lot of third-party code is dual-version/single-source libs, and you definitely don't want to unconditionally call str on a path argument that may be Unicode in 2.7 (or to unconditionally call a six-style Unicode function on a path argument that may be str in 2.7 on Linux).

So, assuming we all want a future in which pathlib is actually used by people, and assuming str subclassing is out and there's no other magic bullet, how do we get there from here?