[Python-Dev] When should pathlib stop being provisional? (original) (raw)
Sven R. Kunze srkunze at mail.de
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:
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).
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 ]