<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, 8 Apr 2016 at 09:39 Ethan Furman <<a href="mailto:ethan@stoneleaf.us">ethan@stoneleaf.us</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 04/08/2016 09:04 AM, Chris Barker wrote:<br>
> On Fri, Apr 8, 2016 at 2:50 AM, Nick Coghlan wrote:<br>
<br>
>> Method, as long as there's a helper function somewhere<br>
><br>
> what has the helper function got to do with whether it's a method or<br>
> attribute (would we call a property an attribute here?)<br>
><br>
>> Built-in? (name is dependent on #1 if we add one)<br>
><br>
> os.fspath (alongside os.fsencode and os.fsdecode)<br>
><br>
> [...] this is only going to be used by the stdlib and other<br>
 > path-using libraries, not user code -- is that that hard to<br>
 > call obj.__fspath__() ?<br>
<br>
1) user code may call it<br>
2) folks who write libraries are still users ;)<br>
3) using __dunder__s directly is usually poor form.<br>
<br>
> I thought the whole point off all this is that not any old string can be<br>
> a path! (whereas any int can be an index). Unless we go with Chris A's<br>
> suggestion that this be a more generic lossless string protocol, rather<br>
> than just for paths.<br>
<br>
That does seem to be a valid point against str.__fspath__.<br></blockquote><div><br></div><div>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).</div></div></div>