The Python Steering Council is seeking your input regarding accepting and landing PEP-649 in a CPython release. If accepted as we’ve stated we expect to do, the question of how soon it becomes the default needs deciding.
TL;DR background
PEP-649 resolves issues blocking PEP-563’s from __future__ import annotations from becoming the default by offering a different way forward. A viable alternative to that future.
649 maintains the ability for what we believe is the majority of code to introspect annotations at runtime as they do today, unlike 563 which turned the annotation into a str. So 649 behavior should be transparent.
The behavior, naturally, is not identical. Evaluation of the annotation is deferred until something actually introspects it. This could lead to side effects and oddities. In practice these are not expected to occur.
The Question
- #1 Make the deferred evaluation to annotations behavior change immediately (3.12).
-
#2 Add another
from __future__ import {bikeshed}directive to enable deferred evaluation of annotations per file (until 3.14). - I don’t care / I trust the Steering Council.
0 voters
Arguments in favor of #1
It is expected to be a no-op for most anything that exists. Runtime use of type annotations is uncommon, known uses are limited to a few projects which we’re led to believe do not have wide adoption. PEP 649 deferred annotations aims to satisfy those where 563 strings did not.
Even if a new default behavior is delayed, code using annotations needs to be ready for it immediately as a future import does it on a per-file basis which will often be in files far removed from the code processing annotations at runtime.
Rebuttals against #1
Even if the norm is identical resulting behavior, it is a behavior change due to the implementation triggering evaluation at a different point in time. Exceptions from evaluation could be raised where they previously were not. Referenced scopes could change in unusual ways.
Arguments in favor of #2
This would let individual files opt-in to the new behavior as needed, allowing a slower transition.
This is our normal breaking behavior change deprecation policy period.
Rebuttals against #2
We already have one __future__ import for annotations. Adding another one adds confusion. (both at once would be a SyntaxError)
A __future__ import for this won’t add value in the right places as it must be done per file and most libraries will not opt-in to the new future import (and cannot do so for 3-7 years when 3.12 is the minimum Python version they support). So it may not practically let people test if things work.
Code processing annotations at runtime needs to be ready for the change as soon as it is implemented regardless of what the default behavior is.
Other options?
Please head over to the discussion thread.
Please do not reply on this poll thread
Lets focus discussion over in PEP 649: Deferred evaluation of annotations, tentatively accepted where the community can participate. This poll was posted here as a Committers only survey and for greater visibility than posting it as a reply on the discussion thread as not everyone may be following that.