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

[Ethan Furman]

On 04/05/2016 03:55 PM, Guido van Rossum wrote:

> It's been provisional since 3.4. I think if it is still there in 3.6.0
> it should be considered no longer provisional. But this may indeed be
> a test case for the ultimate fate of provisional modules -- should we
> remove it?

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.

> Would making it inherit from str cause most hostility to disappear?

I don't think that is necessary.  The hostility (of which I have some) 
is because we can't do:

     app_root = Path(...)
     config = app_root/'settings.cfg'
     with open(config) as blah:
         # whatever

It feels like instead of addressing this basic disconnect, the answer 
has instead been:  add that to pathlib!  Which works great -- until a 
user or a library gets this path object and tries to use something from 
os on it.

To come at this from a different angle:  Python now has Enum; it is 
arguable that Path is more important, or at least much more useful.  We 
have IntEnum whose sole purpose in life is to make it possible to 
(mostly) seamlessly work with the stdlib and other libraries where ints 
are being used to represent enumerations; and in pathlib we have . . . 
absolutely nothing.  We have the promise of great things and wonderful 
usability, but in reality we have just as much pain as before -- or more 
if we forget to str(path) somewhere.

I said that pathlib.Path does not need to inherit from str, and I still 
think that; however, to be a good stepping stone / transitional library 
I think the pathlib backport does need to have its Paths inherit from str.

--
~Ethan~