On Fri, May 5, 2017 at 9:30 PM, Nick Coghlan <ncogh...@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 | ncogh...@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.bar...@noaa.gov
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
