Personally, I think that stringified annotations should be deprecated and eventually be removed. This opens the design space to use quotes for different purposes, for example getting rid of the cumbersome need to use Literal for literals.Keeping the future import and stringified annotations around is certainly an option, but we’re worried about the cost of the implementation, the support cost, and the confusion for users (specifically, it is a future import that will never become the future). If we do keep them, how long would we keep them around? Should we warn about their use? If we warn about the future import, is the noise and confusion this generates going to be worth it? If we don't warn about them, how will we ever be able to turn them off?
+1One thing we’re thinking of specifically for the future import, and for other deprecations in Python, is to revisit the deprecation and warning policy. We think it’s pretty clear that the policy we have right now doesn’t exactly work. We used to have noisy DeprecationWarnings, which were confusing to end users when they were not in direct control of the code. We now have silent-by-default DeprecationWarnings, where the expectation is that test frameworks surface these warnings. This avoids the problem of end users being confused, but leaves the problem of the code’s dependencies triggering the warning, and thus still warns users (developers) not necessarily in a position to fix the problem, which in turn leads to them silencing the warning and moving on. We need a better way to reach the users in a position to update the code.
If we do need a warning, how loud, and how long should it be around? At the end of the deprecation period, should the future import be an error, or simply be ignored?
The future import should remain active and should continue to work as it does now (without warning) as long as there are Python versions supported that have not implemented PEP 649, i.e. Python 3.10. Otherwise, existing code that provides supports for these older versions (especially libraries) have to regress their typing support. For example, a library supporting 3.8+ could have the following code:
from __future__ import annotations
def foo(x: int | str): pass
If newer versions stop supporting the future import or warn about it, the library would have to go back to using typing.Union here. Other constructs would even be impossible to use.
After that, I would recommend to start the normal "warn"/"remove"
cycle for the future import. Don't keep it around if it's doing
nothing.