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

[Nick Coghlan]

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