(For the record, I'm not responding for the whole SC here.) On Wed, Apr 21, 2021 at 12:08 AM Terry Reedy <tjre...@udel.edu> wrote:
> 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. -- Thomas Wouters <tho...@python.org> Hi! I'm an email virus! Think twice before sending your email to help me spread!
_______________________________________________ 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/SLGYN5WFIKAU2HLUNIMPZW4SBPDZA3BF/ Code of Conduct: https://www.python.org/psf/codeofconduct/
