[Python-Dev] When should pathlib stop being provisional?
Sven R. Kunze
srkunze at mail.de
Wed Apr 6 16:47:05 EDT 2016
More information about the Python-Dev mailing list
Wed Apr 6 16:47:05 EDT 2016
- Previous message (by thread): [Python-Dev] When should pathlib stop being provisional?
- Next message (by thread): [Python-Dev] When should pathlib stop being provisional?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 06.04.2016 07:00, Guido van Rossum wrote: > On Tue, Apr 5, 2016 at 9:29 PM, Ethan Furman <ethan at stoneleaf.us> wrote: >> [...] 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. > I agree that asking for config.open() isn't the right answer here > (even if it happens to work). How come? > 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? I think so. Although in this example I would prefer the shorter config.open alternative as I am lazy. I still cannot remember what the concrete issue was why we dropped pathlib the same day we gave it a try. It was something really stupid and although I hoped to reduce the size of the code, it was less readable. But it was not the path->str issue but something more mundane. It was something that forced us to use os[.path] as Path didn't provide something equivalent. Cannot remember..... Best, Sven
- Previous message (by thread): [Python-Dev] When should pathlib stop being provisional?
- Next message (by thread): [Python-Dev] When should pathlib stop being provisional?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list