[Python-Dev] Defining a path protocol

[Brett Cannon]

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>