(original) (raw)



On Fri, 8 Apr 2016 at 09:39 Ethan Furman <ethan@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).