(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!
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!