On 4/20/2021 2:57 PM, Thomas Wouters wrote:
We need to roll back the change that made stringified annotations the default, at least for 3.10. (Pablo is already working on this.)
I also agree and thank Pablo in advance. .
- PEP 563 provides no warning to users of the feature it’s disabling.
Removals or major changes to callables usually get deprecation warnings. These are relatively easy to add by adding code to the object, to be triggered at runtime. I believe something similar can be done with modules, triggered on import, but I have never been involved with such.
Warning about other behavior changes may be needed just as much, but are likely to be harder. I think removing the ability to get object annotations is such a case. It was and needed and likely will be for 3.10, depending on what we decide for 3.11. But the need for a warning would have been and likely will be dependent on the presence of a __future__ import. So the compiler will have to be involved somehow.
The addition of with statements, for instance, was quite different and on balance did not need a deprecation statement. The breaking behavior change was removing 'with' as a candidate for name binding. Detecting such bindings would have been relatively expensive, while the consequence of being caught unaware was having to change a name later rather than sooner, but not losing the underlying code behavior.
The nearest parallel I can think of to this syntax-related type change is the switch for string exceptions to exception subclass exceptions. I believe that at the end, raise 'somestring' got a deprecation notice. This difference is the the change was in the syntax input, where as the annotation change is in the somewhat hidden syntax output.
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.)
Yes, discussion should continue now both while the issue is 'hot' and because adding an appropriate deprecation warning in 3.10.0 requires a decision before it becomes final.
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.
Broadly speaking, statements are functions and their output, as well as input, should be subject to our normal deprecation and suggested replacement policy.
-- Terry Jan Reedy _______________________________________________ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@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/LRO2L7HI7S5U7G32RBZXDBOJVIHV7MP3/ Code of Conduct: https://www.python.org/psf/codeofconduct/
