On 9 May 2017 at 05:08, Chris Barker <chris.bar...@noaa.gov> wrote: > 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.
Exactly - the key barrier to adoption was the lack of "os.fspath()", since it meant that neither the standard library *nor* third party helper libraries could reliably deal with the conversion task on behalf of their users. Instead, people had to carefully manage their own code, ensuring both that they used str() in the appropriate places, *and* that they didn't accidentally call str() on the wrong thing. os.fspath() changes that to be much simpler and friendlier to an iterative development process: 1. By default, expect things to just work 2. If they blow up with TypeError, wrap the offending argument in a call to os.fspath() 3. (optional) file an RFE with the maintainers of the affected API to call os.fspath() implicitly on that argument The number of APIs that fall into the second category is going to be non-zero for quite a while (both in the standard library and elsewhere), but enough folks proceeding to step 3 will bring it down over time. Outside customers complaining to their commercial support vendors though, it's rarely helpful to insist to maintainers (whether of standard library modules or third party ones) that their failure to adopt a feature only added in the latest version of Python now counts as a bug in their software. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
