[Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)
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?
> 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
> 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)
> 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 :)
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Dev