While I have not been involved in the release process for like 15 years or more, I would like to point out that breaking changes mean the distros are less likely to ship them, and be less likely to trust updates.

Trying to get RH &c to stop shipping 1.5.2 was a huge effort. 

Always, any time when you might need to break compat it's a huge risk. 

On Wed, 21 Apr 2021, 4:58 am Thomas Wouters, <thomas@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 <thomas@python.org>

Hi! I'm an email virus! Think twice before sending your email to help me spread!
_______________________________________________
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-leave@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/CLVXXPQ2T2LQ5MP2Y53VVQFCXYWQJHKZ/
Code of Conduct: https://www.python.org/psf/codeofconduct/