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

[Nick Coghlan]

On 6 May 2017 at 05:36, Chris Barker <chris.barker at noaa.gov> wrote:
> It doesn't actually say "everywhere possible in the stdlib", but if the goal
> is to facilitate migration, as stated, then the any but truly obscure
> functions should be covered -- and shutil is certainly not obscure.
>
> So it would be really great if any updates to shutils (and other stdlib
> packages) to support the new protocol be back-ported.

This argument would apply to all the other protocols we've added over
time, and would lead to significant language churn in maintenance
releases if we regularly relied on it.

As another example from 3.6, we found that the non-type metaclasses in
the standard library (most notably abc.ABCMeta) don't play nice with
the arbitrary keyword support in __init_subclass__, since they don't
pass the additional keywords from the class definition up to
type.__new__ (which in turn would pass them along to
__init_subclass__).

That's an oversight we're definitely going to fix, but we'll fix it in
3.7, not in 3.6.x.

> Yes, it's "just" adding an extra call, but in my experience, low barrier to
> entry are enough to discourage adoption -- and handful of shutil function
> failing will certainly be enough to keep some folks from adopting the new
> approach.

The critical problem prior to 3.6 wasn't the extra call, it was that
the recommended extra call had the undesirable side effect of allowing
*any* object to be used as a "file system path". As a result, you
couldn't easily separate the check out into a helper function without
putting a lot of annoying "isinstance" checks into it (or else relying
on functools.singledispatch).

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.

> 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