I'm sorry, I sent my last mail too early. Here are the rest of my thoughts.
Am 20.10.21 um 15:18 schrieb Thomas Wouters:
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?
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.
One 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.
+1
1.
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.
- Sebastian
_______________________________________________
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/RHSQFTTCTPIH4X3XCQBYXFSAO3I6CTBN/
Code of Conduct: http://python.org/psf/codeofconduct/