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

[Eric V. Smith]

On 5/5/2017 3:36 PM, Chris Barker wrote:
> Sorry to come late to the game, It wasn't immediately clear to me what 
> the implications were of the "enhancement or bugfix" distinction...
> 
> On Thu, May 4, 2017 at 9:46 PM, Nick Coghlan <ncoghlan at gmail.com 
> <mailto:ncoghlan at gmail.com>> wrote:
> 
>     That improved casting mechanism and the implicit support in the low
>     level APIs is the main benefit I see in PEP 519, and if we were
>     talking about an os module API that was missing os.path support, I'd
>     be more likely to be on the "it's a bug" side of things.
> 
> 
> absolutely.
> 
>     It's only higher level APIs like shutil that I put into the same
>     category as third party libraries for now: Python 3.6 users shouldn't
>     expect implicit use of the fspath protocol to be universal yet,
> 
> 
> I think stdlib packages, like shutil are very much distinct from third 
> party  libs, and users certainly expect the entire stdlib to be updated 
> to support new language features.
> 
> We very often make the distinction between third party libs and stdlibs 
> -- in fact, that is one reason we are reluctant to add new packages to 
> the stdlib...
> 
> Indeed, IIRC, that was the entire motivation for PEP 519 -- it started 
> as a "let's make Path objects work with the stdlib", but when we looked 
> at how to do that, it became clear that new protocol was teh best way to 
> do that and also provide flexibility to do that.
> 
> And the PEP states:
> 
> """
> Changes to Python's standard library are also proposed to utilize this 
> protocol where appropriate to facilitate the use of path objects where 
> historically only str and/or bytes file system paths are accepted. The 
> goal is to facilitate the migration of users towards rich path objects 
> while providing an easy way to work with code expecting str or bytes .
> """
> 
> 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.
> 
> 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.
> 
> Is there any chance of it breaking already working code? That would be 
> the one compelling reason to not back-port.

The problem is not breaking existing code. The problem is that when 
someone writes code a year from now and tests it under Python 3.6.2, 
then a customer of theirs finds it doesn't work in 3.6.1. This will 
happen if 3.6.2 supports Path parameters to functions that 3.6.1 does not.

We've burned ourselves before with this, most famously with True and 
False in 2.2.1: 
http://python-history.blogspot.com/2013/11/the-history-of-bool-true-and-false.html

--
Eric.