[Python-ideas] Better stdlib support for Path objects

[Terry Reedy]

On 10/6/2014 2:04 PM, Guido van Rossum wrote:
> On Mon, Oct 6, 2014 at 10:47 AM, Barry Warsaw
> <barry at python.org
> <mailto: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.
>
>     Cheers,
>     -Barry
>
>     [*] https://mail.python.org/pipermail/python-ideas/2014-May/027869.html

To me, the first question to me is whether we 'believe' in pathlib
enough to really support it in the stdlib and encourage its use.

> I'd turn it around.
>
> You can construct a Path from an argument that can be either a string or
> another Path. Example:
>
>  >>> from pathlib import Path
>  >>> p = Path('/etc/passwd')
>  >>> q = Path(p)
>  >>> p == q
> True
>  >>>
>
> So you could start refactoring stdlib code to use Path internally
> without forcing the callers to use Path, but still *allow* the callers
> to pass a Path.

If yes (which the above seems to hint), the second question is how to 
enlarge apis while remaining back compatible.  For functions that take a 
pathstring in and do not return a pathstring,  just allow a Path as 
alternate input type.  There are already functions that take either a 
pathstring or open file-like object.

 > Though I'm not sure how this would work for return
> values without breaking backwards compatibility -- you'd have to keep
> returning strings and the callers would have to use the same mechanism
> to go back to using Paths.

Some of the os functions that take a pathstring and return a pathstring 
are already 'duplicated' as pathlib functions or Path methods that map 
Path to Path.  For others, there is a choice of duplicating the function 
in pathlib or making the output type depend on the input type.

I do not remember the current scandir spec, but it should when 
introduced at least optionally accept and produce paths and perhaps live 
in pathlib instead of os.

I suspect that functions that produce a pathstring without a pathstring 
input, such as int file descriptor to filename, are rare and low-level 
enough to leave as is.  But that should be specified in any 
transition-plan pep.

-- 
Terry Jan Reedy