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. 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. >> - the names would be fspath and __fspath__, since the result may be >> either a path name as text, or an encoded path name as bytes > > You just used the phrase "path name as bytes" -- so why is > __pathname__ inappropriate if it might return bytes? No, he used the phrase "*encoded* path name as bytes". Names are typically represented as text, and since bytes might be returned we don't want a signal that says text. > I like __pathname__ better because this entire effort is because we' > be decided itMs important to make the distinction between a "path" and > the text representation of said path. No, this entire effort is to make pathlib work with the rest of the stdlib. -- ~Ethan~
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