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

[Nick Coghlan]

On 7 April 2016 at 03:26, Brett Cannon <brett at python.org> wrote:
> WIth Ethan volunteering to do the work to help make a path protocol a thing
> -- and I'm willing to help along with propagating this through the stdlib
> where I think Serhiy might be interested in helping as well -- and a seeming
> consensus this is a good idea, it seems like this proposal has a chance of
> actually coming to fruition.
>
> Now we need clear details. :) Some open questions are:
>
> Name: __path__, __fspath__, or something else?

__fspath__

> 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

> 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)

> 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

> 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)

> Some people have asked for the pathlib PEP to have a more flushed out
> reasoning as to why pathlib doesn't inherit from str. If Antoine doesn't
> want to do it I can try to instil my blog post into a more succinct
> paragraph or two and update the PEP myself.
>
> Is this going to require a PEP or if we can agree on the points here are we
> just going to do it? If we think it requires a PEP I'm willing to write it,
> but I obviously have no issue if we skip that step either. :)

It's worth summarising in a PEP at least for communications purposes -
very easy for folks that don't follow python-dev to miss otherwise.
Plus my specific API suggestions are pretty different from Ethan's :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia