<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, 7 Apr 2016 at 13:46 Paul Moore <<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 7 April 2016 at 21:28, Ethan Furman <<a href="mailto:ethan@stoneleaf.us" target="_blank">ethan@stoneleaf.us</a>> wrote:<br>
> In case there's any confusion: by "not work" I mean the stdlib is not going<br>
> to correctly interpret a pathlib.Path in 3.3 and earlier.<br>
<br>
I think the confusion is over *who* will be checking the protocol or<br>
the ABC. You're correct that the stdlib will not do so in earlier<br>
versions. I've been assuming that is obvious (and I suspect Brett has<br>
too).</blockquote><div><br></div><div>Yep, you're right. I was never worried about making the stdlib work since that's a fully controlled environment that we can update at once. What I'm worried about is any third-party library that has an API that takes a path as an argument that may need to be updated to support pathlib -- or any other path library -- and doesn't want to directly rely on Python 3.6 for support.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Talk about using the check for older versions is basically<br>
around the possibility that 3rd party libraries might do so. I think<br>
it's unlikely that they'll bother (but I'm commenting on the<br>
suggestion because I'd like it to be easy to do if anyone does want to<br>
bother, against my expectations). I have the feeling Brett might think<br>
that it's somewhat more likely.<br></blockquote><div><br></div><div>Yes, that's my hope as third-party libraries are the ones that have older Python version compatibility to care about (the stdlib is obviously always latest-and-greatest).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If all we're thinking about is a way for the stdlib to work with<br>
strings and pathlib objects seamlessly, while also allowing 3rd party<br>
path classes to register to be treated the same way, then yes, there's<br>
no real difference between an ABC and a protocol (well, to register<br>
with the ABC, 3rd party code would need to conditionally import the<br>
ABC and make sure not to fail if the ABC can't be found, but that's<br>
just some boilerplate).<br></blockquote><div><br></div><div>My point is the boilerplate is minimized for third-party libraries in the instance of the magic method vs the ABC, but otherwise they accomplish the same thing.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Frankly, if it wasn't for the fact that you have stated that you'll<br>
add support for the protocol to your path library, I'd be surprised if<br>
*any* 3rd party code changed as a result of this discussion. There's<br>
been no comment from the authors of path.py or pylib (the only other 2<br>
path objects I know of). And the only comments I've heard from authors<br>
of libraries that consume paths is "I don't see any reason why I'd<br>
bother". So as long as you're happy with the final form of the<br>
proposal, I see little reason to worry about how other 3rd party code<br>
might use it.<br></blockquote><div><br></div><div>I'm trying to be a bit more optimistic on the uptake. :) </div></div></div>