<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, May 5, 2017 at 9:30 PM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">By contrast, 3.6 users can just unconditionally call os.fspath(), and<br>
know the result will work with all stdlib APIs, without allowing<br>
nonsense like attempting to use "str(str)" as a filesystem path.<br></blockquote><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Doing that implicitly in various APIs is certainly a nice UX<br>
enhancement, but it's the replacement of str with os.fspath as the<br>
recommended coercion function that removes the major barrier to<br>
pathlib adoption.</blockquote><div><br></div><div>honestly, I'm not sure about that -- burying a str() call in a lib is clearly risky, but using one in your user code, not so much -- you usually know you have a path-like object (if not a Path) itself. the extra need for wrapping str() around things was a barrier to pathlib adoption -- and it doesn't take much of a barrier to reduce the adoption of something new.</div><div><br></div><div>The goal is clearly that ALL stdlib function take a path_like -- but if we're not there yet, we're not there yet :-(</div><div><br></div><div>-CHB</div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> Is there any chance of it breaking already working code? That would be the<br>
> one compelling reason to not back-port.<br>
<br>
</span>"Don't make the third party compatibility testing matrix impossibly<br>
complicated" is our other major reason not to backport new features.<br>
<br>
We already have platform providers supporting 3.6.0 in the wild<br>
(Heroku and AWS Lambda), and we know 3.6.1 is going to be in at least<br>
Fedora 26, and probably Ubuntu 17.10.<br>
<br>
We want CI providers like Travis/GitLab/Circle CI/etc to be able to<br>
provide a *single* 3.6.x release (typically the most recent one), and<br>
have the guarantee be "code that passes on this maintenance release<br>
will only fail on earlier maintenance releases if you hit a genuine<br>
bug in those releases".<br>
<br>
Changing a function signature from accepting "Union[str, bytes]" (or<br>
potentially even just "str") to instead accepting "os.PathLike"<br>
doesn't count as fixing a genuine bug in the earlier releases - it<br>
just means we made the API more permissive in a maintenance release.<br>
<div class="HOEnZb"><div class="h5"><br>
Cheers,<br>
Nick.<br>
<br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="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>