On 7 April 2016 at 03:26, Brett Cannon <br...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
