[Python-Dev] When should pathlib stop being provisional? (original) (raw)

Ethan Furman ethan at stoneleaf.us
Wed Apr 6 00:29:18 EDT 2016

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

More information about the Python-Dev mailing list