This is amazing news! On behalf of the FastAPI/pydantic communities, thanks to the Steering Council, and everyone involved!
I understand the big effort and commitment the Steering Council is making with this decision to support the pydantic and FastAPI communities (especially with our short notice), and the last-minute extra work involved in reverting the default for 3.10. This will give us all the time to figure out how to handle it taking into account pydantic/FastAPI and the use cases that would benefit from PEP 563 and PEP 649. Thanks! Sebastián On Tue, Apr 20, 2021 at 9:14 PM Guido van Rossum <gu...@python.org> wrote: > Thanks to the Steering Council! You have the wisdom of Solomon. Rolling > back the code that made PEP 563 the default behavior is the only sensible > solution for 3.10. > > On Tue, Apr 20, 2021 at 11:58 AM Thomas Wouters <tho...@python.org> wrote: > >> >> (Starting a new thread so as not to derail any of the ongoing >> discussions.) >> >> Thanks, everyone, for your thoughts on Python 3.10 and the impact of PEP >> 563 (postponed evaluation of annotations) becoming the default. The >> Steering Council has considered the issue carefully, along with many of the >> proposed alternatives and solutions, and we’ve decided that at this point, >> we simply can’t risk the compatibility breakage of PEP 563. We need to roll >> back the change that made stringified annotations the default, at least for >> 3.10. (Pablo is already working on this.) >> >> To be clear, we are not reverting PEP 563 itself. The future import will >> keep working like it did since Python 3.7. We’re delaying making PEP 563 >> string-based annotations the default until Python 3.11. This will give us >> time to find a solution that works for everyone (or to find a feasible >> upgrade path for users who currently rely on evaluated annotations). Some >> considerations that led us to this decision: >> >> - PEP 563’s default change is clearly too disruptive to downstream users >> and third-party libraries to happen right now. We can’t risk breaking even >> a small subset of the FastAPI/pydantic users, not to mention other uses of >> evaluated type annotations that we’re not aware of yet. >> - PEP 563 provides no warning to users of the feature it’s disabling. >> Without that, we can’t expect users to be aware of the upcoming breakage. >> The lack of a warning was by design, and made sense in a world where type >> annotations were only consumed by static type checkers --- but that’s not >> actually the situation we’re in. There are clearly existing real-world, >> run-time uses of type annotations that would be adversely affected by this >> change. >> - Originally, PEP 563 was scheduled to take effect in Python 4, and this >> changed recently (after the discussion in the Language Summit of 2020). >> It's possible that third-party libraries and users didn’t plan to react in >> the current time frame as they were not aware of this change in timing. >> - There isn’t enough time to properly discuss PEP 649 or any of the >> alternatives before the beta 1 deadline, and we really need to make sure we >> don’t compound errors here. We need to look for a long term solution, >> which isn’t possible while still maintaining the release deadlines of >> Python 3.10. That means we’re also deferring PEP 649 to Python 3.11. >> >> In the Steering Council’s unanimous opinion, rolling back the default >> flip for stringified annotations in Python 3.10 is the least disruptive of >> all the options. >> >> We need to continue discussing the issue and potential solutions, since >> this merely postpones the problem until 3.11. (For the record, postponing >> the change further is not off the table, either, for example if the final >> decision is to treat evaluated annotations as a deprecated feature, with >> warnings on use.) >> >> For what it’s worth, the SC is also considering what we can do to reduce >> the odds of something like this happening again, but that’s a separate >> consideration, and a multi-faceted one at that. >> >> For the Steering Council, >> Thomas. >> -- >> Thomas Wouters <tho...@python.org> >> >> Hi! I'm an email virus! Think twice before sending your email to help me >> spread! >> _______________________________________________ >> python-committers mailing list -- python-committ...@python.org >> To unsubscribe send an email to python-committers-le...@python.org >> https://mail.python.org/mailman3/lists/python-committers.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-committ...@python.org/message/CLVXXPQ2T2LQ5MP2Y53VVQFCXYWQJHKZ/ >> Code of Conduct: https://www.python.org/psf/codeofconduct/ >> > > > -- > --Guido van Rossum (python.org/~guido) > *Pronouns: he/him **(why is my pronoun here?)* > <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/4BFSYEKU3P7FNRKVDD7RZXTNEEA6PRXU/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/6WI5IQFIUEVBGXDDKRTSRWGQMALZJNUU/ Code of Conduct: http://python.org/psf/codeofconduct/
