[Python-Dev] Defining a path protocol (original) (raw)

Brett Cannon brett at python.org
Fri Apr 8 13:34:57 EDT 2016

On Fri, 8 Apr 2016 at 09:39 Ethan Furman <ethan at stoneleaf.us> wrote:

On 04/08/2016 09:04 AM, Chris Barker wrote: > On Fri, Apr 8, 2016 at 2:50 AM, Nick Coghlan wrote:

>> Method, as long as there's a helper function somewhere > > what has the helper function got to do with whether it's a method or > attribute (would we call a property an attribute here?) > >> Built-in? (name is dependent on #1 if we add one) > > os.fspath (alongside os.fsencode and os.fsdecode) > > [...] this is only going to be used by the stdlib and other > path-using libraries, not user code -- is that that hard to > call obj.fspath() ? 1) user code may call it 2) folks who write libraries are still users ;) _3) using dunder_s directly is usually poor form. > I thought the whole point off all this is that not any old string can be > a path! (whereas any int can be an index). Unless we go with Chris A's > suggestion that this be a more generic lossless string protocol, rather > than just for paths. That does seem to be a valid point against str.fspath.

Yep, and I'm expecting we won't want that at this point. The fact that paths need strings for low-level OS stuff is a historical and technical detail, so no need to drag the entire str type into it if we can provide a reasonable helper function (for either the ABC or magic method solution). -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20160408/7dc3cdc2/attachment.html>

More information about the Python-Dev mailing list