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

Nick Coghlan ncoghlan at gmail.com
Tue May 9 01:00:48 EDT 2017

On 9 May 2017 at 05:08, Chris Barker <chris.barker at noaa.gov> wrote:

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.

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 | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list