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@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.

-CHB



--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov