On 4/20/2021 2:57 PM, Thomas Wouters wrote:
> - 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.
I'm not sure what point you're trying to make here. Use of 'with' as identifier *was* detected. They *were* warned about. It wasn't particularly expensive. This is why __future__.with_statement exists. In Python 2.5, using 'with' (and 'as') as identifiers issued a warning. You couldn't use 'with' as a statement without using the future import.
The idea that we should warn before significant changes to behaviour -- documented behaviour, like function annotations being evaluated at definition time, or behaviour commonly depended on, like 'with' being allowed as an identifier because it wasn't explicitly listed as a keyword -- is not new. It's covered by PEP 387:
https://www.python.org/dev/peps/pep-0387/
The question isn't really whether we should raise a warning, or whether we can, the question is how much effort it's going to be. I'm sure it could be done by, for example, making a new API (for example, putting stringified annotations in a different attribute) and warning on any use of the old API (if we decide to go forward with PEP 563 over the alternatives). That would be more disruptive to code already adjusted for stringified annotations, so perhaps there are better alternatives.
It may be that we need to adjust the expectations around PEP 387 (our own and our users') if we find that making desirable changes becomes difficult. Perhaps we need different safeguards against incompatible changes than "make sure users have a chance to see warnings for at least 2 releases". For example, perhaps we need a separate validation tool, something that will analyse code and tell the user if their code is going to be safe for a particular Python release. That would be a big undertaking, since it's not enough to provide such a tool, we also have to make very clear that users need to use it if they want to be compatible with future Python releases. (I just say 'users' here, but we all know there are very many different kinds of users of Python, so it's not as simple as putting out a blog post either.)
In the meantime we should strive to honour the commitments we made in PEP 387 and elsewhere, and not pull the rug out from under users.
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.
What I meant by that paragraph was more along the lines of making sure third-party uses of Python feel comfortable bringing these issues to our attention earlier.