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

Ethan Furman ethan at stoneleaf.us
Wed Apr 6 02:50:06 EDT 2016


On 04/05/2016 10:00 PM, Guido van Rossum wrote:

On Tue, Apr 5, 2016 at 9:29 PM, Ethan Furman <ethan at stoneleaf.us> wrote:

[...] we can't do:

approot = Path(...) config = approot/'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. I agree that asking for config.open() isn't the right answer here (even if it happens to work). But in this example, once 3.5.2 is out, the solution would be to use open(config.path), and that will also work when passing it to a library. Is it still unacceptable then?

On the one hand that is definitely more palatable.

On the other hand it doesn't address having the stdlib itself directly support Path.

On the gripping hand this feels reminiscent of the arguments over bytes vs unicode, but without any of the "This is why unicode is better!" bits.

Why is pathlib better than plain strings?

What problem is it solving that makes the pain worth dealing with?

This is an especially important point considering the str-derived Path libraries already out there that have the same advantages as pathlib, but none of the pain.

-- Ethan



More information about the Python-Dev mailing list