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

Michel Desmoulin desmoulinmichel at gmail.com
Thu Apr 7 06:50:42 EDT 2016

Le 06/04/2016 22:47, Sven R. Kunze a écrit :

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.....

Path objects don't have splitext() or and don't allow "string" / path. Those are the ones bugging me the most.

Best, Sven

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/desmoulinmichel%40gmail.com

More information about the Python-Dev mailing list