Sorry for disturbing this thread's harmony.
On 12.04.2016 08:00, Ethan Furman wrote:
On 04/11/2016 10:14 PM, Chris Barker - NOAA Federal wrote:
Consider os.path.join:
Why in the world do the os.path functions need to work with Path
objects? ( and other conforming objects)
Because library XYZ that takes a path and wants to open it shouldn't
have to care whether that path is a string or pathlib.Path -- but if
os.open can't use pathlib.Path then the library has to care (or the
user has to care).
This all started with the goal of using Path objects in the stdlib,
but that's for opening files, etc.
Etc. as in os.join? os.stat? os.path.split?
Path is an alternative to os.path -- you don't need to use both.
I agree with that quote of Chris.
As a user you don't, no. As a library that has no control over what
kind of "path" is passed to you -- well, if os and os.path can accept
Path objects then you can just use os and os.path; otherwise you have
to use os and os.path if passed a str or bytes, and pathlib.Path if
passed a pathlib.Path -- so you do have to use both.
I don't agree here. There's no need to increase the convenience for a
library maintainer when it comes to implicit conversions.
When people want to use your library and it requires a string, the can
simply use "my_path.path" and everything still works for them when they
switch to pathlib.
Best,
Sven
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
