On Thu, Apr 7, 2016 at 11:28 AM, Chris Angelico <rosuav@gmail.com> wrote:
Fair enough. That was a spur-of-the-moment thought. To be honest, this
proposal is a massive generalization from, ultimately, a single
use-case.

yes, but now that you say:

... 
 
And this should make it easier for third-party code to be functional
without even being aware of the Path object. There are two basic
things that code will be doing with paths: passing them unchanged to
standard library functions (eg open()), and combining them with
strings. The first will work by definition; the second will if paths
can implicitly upcast to strings.

so this is really a way to make the whole path!=string thing easier -- we don't want to simply call str() on anything that might be a path, because that will work on anything, whether it's the least bit pathlike at all, but this would introduce a new kind of __str__, so that only things for which it makes sense would "Just work":

str + something

Would only concatenate to a new string if somethign was an object that couuld "losslessly" be considered a string?

but if we use the __index__ example, that is specifically "an integer that can be ued as an index", not "something that can be losslessly converted to an integer".

so why not the __fspath__ protocol anyway?

Unless there are all sorts of other use cases you have in mind?

-CHB

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov