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

Nick Coghlan ncoghlan at gmail.com
Fri Apr 8 05:50:04 EDT 2016

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 PyObjectPath()?

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

More information about the Python-Dev mailing list