[Python-Dev] When should pathlib stop being provisional?

Barry Warsaw barry at python.org
Wed Apr 6 15:33:30 EDT 2016

On Apr 05, 2016, at 09:29 PM, Ethan Furman wrote:

>We should either remove it or make the rest of the stdlib work with it.
>Currently, pathlib.*Paths are second-class citizens, and working with them is
>not significantly better than working with os.path.* simply because we have
>to cast to str every time we want to deal with any other part of the stdlib.

This.  I've tried to use them in a couple of projects and in many ways pathlib
objects are nice to work with.  But rarely can they be used exclusively.
There are just too many other packages and APIs that use os.path and the two
do not interoperate very well.  That makes practical use of pathlib objects
just too unwieldy for project-wide adoption.

I don't know if inheriting them from str would fix this problem.  I'm +0 on
removing the provisional status of pathlib and in trying to figure out ways
for them to work better with other libraries (both stdlib and 3rd party) that
will continue to be os.path based for the foreseeable future.


More information about the Python-Dev mailing list