[Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

[Koos Zevenhoven]

Nick Coghlan wrote:
> On 7 April 2016 at 03:26, Brett Cannon <br... at python.org> wrote:
>>
>> Name: __path__, __fspath__, or something else?
>
> __fspath__
>

I think I might like this dunder name because it does not clutter the
list of regular methods and attributes, and is perhaps more pythonic.

>> Method or attribute? (changes what kind of one-liner you might use in
>> libraries, but I think historically all protocols have been methods and the
>> serialized string representation might be costly to build)
>
> Method, as long as there's a helper function somewhere

As a further minor benefit of it being a method, it may be easier to
distinguish it from from `__path__`, which is an iterable attribute.

>> Built-in? (name is dependent on #1 if we add one)
>
> os.fspath (alongside os.fsencode and os.fsdecode)
>
> (Putting this in a module low in the dependency stack makes it easy
> for other modules to access without pulling in all of pathlib's
> dependencies)

Strong +1 on putting it in os. This should also be implemented in
DirEntry, instances of which are "yielded" by os.scandir.

Also, you have a strong case regarding naming with the 'fs' prefix. It
is also easier to read fspath as f-s-path than it is to read ospath as
o-s-path, because ospath could also be pronounced as a single
(meaningless?) word.

I'm still thinking a little bit about 'pathname', which to me sounds
more like a string than fspath does [1]. It would be nice to have the
string/path distinction especially when pathlib adoption grows larger.
But who knows, maybe somewhere in the far future, no-one will care
much about fspath, fsencode, fsdecode or os.path.

>> Add the method/attribute to str? (I assume so, much like __index__() is on
>> int, but I have not seen it explicitly stated so I would rather clarify it)
>
> Makes sense

If added to str, it should also be added to bytes. But will that then
return str or bytes? See also the next point.

> Expand the C API to have something like PyObject_Path()?
>
> PyUnicode_FromFSPath, perhaps? The return type is well-defined here,
> so it can be done as an alternate constructor, and the C API
> counterparts of os.fsdecode and os.fsencode are PyUnicode functions
> (specifically PyUnicode_DecodeFSDefault and PyUnicode_EncodeFSDefault)

What about DirEntry, which may have a bytes representation? I would
expect the function return type of os.fspath to be Union[str, bytes],
unless bytes pathnames are decoded with surrogate escapes.

[1] https://mail.python.org/pipermail/python-ideas/2016-April/039595.html


PS. I have been reading this list occasionally on the google groups
mirror, and I now subscribed to it just to send this. (BTW, I probably
broke the thread, as I did not have Nick's email in my inbox to reply
to. Sorry about that.) I'll have to mention that I was surprised, to
say the least, to find that the pathlib discussion had moved here from
python-ideas, where I had mentioned I was working on a proposal. Then,
I also found that the solution discussed here was seemingly an
improved version of what I had proposed on python-ideas somewhat
earlier [1], but did not get any reactions to. While I can only make
guesses about what happened, these kinds of things easily make you go
from "Hey, maybe I'll be able to do something to improve Python!" to
"These people don't seem to want me here or appreciate my efforts.".
Not to accuse anyone in particular; just to let people know. Anyway, I
somehow got sucked into thinking deeply about pathlib etc. (which I do
use). Not that I really have much at stake here, except spending
ridiculous amounts of time thinking about paths, mainly during my
Easter holidays and after that. I really had a hard time explaining to
friends and family what the heck I was doing ;).