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

Chris Barker chris.barker at noaa.gov
Mon May 8 15:08:29 EDT 2017

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>

More information about the Python-Dev mailing list