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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4