<p dir="ltr">On Apr 7, 2016 8:57 AM, "Paul Moore" <<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>> wrote:<br>
[...]<br>
> But the proposal for paths is to have a *specific* method that says<br>
> "give me a string representing a filesystem path from this object". An<br>
> "interpret this object as a string" wouldn't be appropriate for the<br>
> cases where I'd want to do "give me a string representing a filesystem<br>
> path". And that's where I get stuck, as I can't think of an example<br>
> where I *would* want the more general option. For a number of reasons:<br>
><br>
> 1. I can't think of a real-world example of when I'd *use* such a facility<br>
> 2. I can't think of a real-world example of a type that might<br>
> *provide* such a facility<br>
> 3. I can't see how something so general would be of benefit.</p>
<p dir="ltr">Numpy and friends would implement this if it existed, for things like converting numpy strings to python strings.</p>
<p dir="ltr">But I can't think of the cases where this would be useful either.</p>
<p dir="ltr">The reason that it's useful to have __index__, and that it would be useful to have __fspath__, is that in both cases there are a bunch of interfaces defined as part of the core language that need to implement the consumer side of the protocol, so a core language protocol is the only real way to go. I'm not thinking of a lot of analogous APIs in core python take specifically-strings? Most of the important ones are str methods, so regular self-dispatch already handles it. Or I guess str.__add__(someobj), but that's already handled by binop dispatch.</p>
<p dir="ltr">-n</p>