[Python-Dev] Is adding support for os.PathLike an enhancement or bugfix?

[Chris Barker]

On Fri, May 5, 2017 at 9:30 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> By contrast, 3.6 users can just unconditionally call os.fspath(), and
> know the result will work with all stdlib APIs, without allowing
> nonsense like attempting to use "str(str)" as a filesystem path.
>


> Doing that implicitly in various APIs is certainly a nice UX
> enhancement, but it's the replacement of str with os.fspath as the
> recommended coercion function that removes the major barrier to
> pathlib adoption.


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.

The goal is clearly that ALL stdlib function take a path_like -- but if
we're not there yet, we're not there yet :-(

-CHB






>
> > Is there any chance of it breaking already working code? That would be
> the
> > one compelling reason to not back-port.
>
> "Don't make the third party compatibility testing matrix impossibly
> complicated" is our other major reason not to backport new features.
>
> We already have platform providers supporting 3.6.0 in the wild
> (Heroku and AWS Lambda), and we know 3.6.1 is going to be in at least
> Fedora 26, and probably Ubuntu 17.10.
>
> We want CI providers like Travis/GitLab/Circle CI/etc to be able to
> provide a *single* 3.6.x release (typically the most recent one), and
> have the guarantee be "code that passes on this maintenance release
> will only fail on earlier maintenance releases if you hit a genuine
> bug in those releases".
>
> Changing a function signature from accepting "Union[str, bytes]" (or
> potentially even just "str") to instead accepting "os.PathLike"
> doesn't count as fixing a genuine bug in the earlier releases - it
> just means we made the API more permissive in a maintenance release.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>



-- 

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 at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170508/0dc160a4/attachment.html>