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~
_______________________________________________
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
