[Python-Dev] Defining a path protocol

Ethan Furman ethan at stoneleaf.us
Wed Apr 6 14:05:47 EDT 2016


On 04/06/2016 10:26 AM, Brett Cannon 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.

Excellent!  Let's proceed along this path ;) until somebody objects.


> Now we need clear details. :) Some open questions are:
>
>  1. Name: __path__, __fspath__, or something else?

__fspath__


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

I would prefer an attribute, but yeah I think dunders are typically 
methods, and I don't see this being special enough to not follow that trend.


>  3. Built-in? (name is dependent on #1 if we add one)

fspath() -- and it would be handy to have a function that return either 
the __fspath__ results, or the string (if it was one), or raise an 
exception if neither of the above work out.


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

I don't think that's needed.  With Path() and fspath() it's trivial to 
make sure one has what one wants.


>  5. Expand the C API to have something like PyObject_Path()?

No opinion.


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

Nice.


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

If there are no (serious?) objects I don't think a PEP is needed.


> Oh, and we should resolve this before the next release of Python 3.4,
> 3.5, or 3.6 so that pathlib can be updated in those releases.

Agreed.

--
~Ethan~



More information about the Python-Dev mailing list