[Python-Dev] pathlib - current status of discussions

[Ethan Furman]

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~