<div dir="ltr">On Wed, Apr 6, 2016 at 5:57 PM, Ethan Furman <span dir="ltr"><<a href="mailto:ethan@stoneleaf.us" target="_blank">ethan@stoneleaf.us</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">But not a big deal. I think this is pretty much for occasional use by<br><span class=""><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
library authors, so not a big deal what it is named.<br>
</blockquote>
<br></span>
It's mostly for the stdlib itself.  I imagine that most libraries would just take what they are given and pass it along to open or os.stat or whatever.<span class=""><br></span></blockquote><div><br></div><div>Exactly -- so we really don't need a builtin shortcut.<br></div><div> <br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Which makes me think: str() calls __str__ on an arbitrary object, and<br>
creates a new string object.<br>
<br>
But fspath(), if it exists, would call __fspath__ on an arbitrary<br>
object, and create a new string -- not a new Path. That may be<br>
confusing...<br>
</blockquote>
<br></span>
It would be more along the lines of pickle -- give me the standard serialized form of this Path, please.<span class=""><br></span></blockquote><div><br></div><div>well, give me the standard serialized-path of this arbitrary object, yes?<br></div><div> <span class=""></span><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So are we imagining that future libs will be written that only take<br>
objects with a __fspath__ method? In which case, do we need to add it<br>
to str? In which case, this is all kind of pointless.<br>
</blockquote>
<br></span>
We are imagining that future libraries that have to muck about with paths will work with Path objects, either by accepting them or converting to them as the (possibly) stringified paths are passed in -- and when necessary those libs can pass either the Path obj or the stringified path to the stdlib.</blockquote><div><br></div><div>if that's the case, we don't need the __fspath__ protocol -- the reason for the protocol is that we imagine there may be any number of third-party objects to represent/work-with paths, that aren't strings or stdlib Path objects.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Or maybe all future libs will continue to accept either an str or an<br>
object with __fspath__.  In which case, this is pretty pointless, too.<br>
</blockquote>
<br></span>
The point is to allow future programs to work with Path and be able to work with the stdlib as seamlessly and painlessly as possible.<span class=""><br></span></blockquote><div><br></div><div>again, we don't need a new protocol for that -- we only need the protocol if we want arbitrary future programs to work with arbitrary path implementations.<br><br></div><div>which I suppose we do -- there are already other path implimentaitons out there (though at least some are strings :-) )<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I guess what I'm wondering is if we are stuck with str-paths as the<br>
lingua-Franca for paths forever. In which case, we should embrace that<br>
and just call str() on anything passed in as a path argument.<br>
</blockquote>
<br></span>
Nah.  That's inviting trouble and pain, and we're trying to get away from that.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Sure, then open(3.5) will give you a file not found error, or maybe<br>
create a file with a weird name, but really? Who's going to make that<br>
mistake and not figure it out really quickly?<br>
</blockquote>
<br></span>
Well, since the 3.5 was actually in my_var, and could have been written before it was read, it could easily be days, weeks, or even months -- probably after the last guy quit, you took the job, the server died, and you had to restore from backup -- at which point you'll see all the really, really strange file names and wonder what they are.  And of course, whatever logic was determining those weird names is now out of sync because of the server swap.<br>
<br>
And, yeah, I've seen weirder things happen.<br></blockquote><div><br></div><div>People can totally screw up path variables as strings or Path objects too -- I'm having trouble seeing that this is all that more likely -- after all, python is a dynamic language -- if we wanted full type safety, we wouldn't be using python...<br><br></div><div>Speaking of which, how is this going to work with the new type system? Do we need an ABC, rather than just a protocol?<br><br></div><div>But as long as we get to the stdlib taking Path objects, I'm happy :-)<br><br></div><div>-CHB<br><br></div></div><br>-- <br><div class="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R            (206) 526-6959   voice<br>7600 Sand Point Way NE   (206) 526-6329   fax<br>Seattle, WA  98115       (206) 526-6317   main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div></div>