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 <ncogh...@gmail.com
<mailto:ncogh...@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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
