At last, a nibble on the other fishing line! ;-)

On 1/11/21 1:47 PM, Brett Cannon wrote:
So the biggest potential breakages are code that:
  1. Directly get the attribute from __dict__
  2. The fact that it would no longer be inherited
Am I missing anything else?

Those are the big ones, the ones I expect people to actually experience.  I can name three more breakages, though these get progressively more obscure:

I have no idea if anybody is depending on these behaviors.  The lesson that years of Python core dev has taught me is: if Python exhibits a behavior, somebody out there depends on it, and you'll break their code if you change it.  Or, expressed more succinctly, any change is a breaking change for somebody.  So the question is, is the improvement this brings worth the breakage it also brings?  In this case, I sure hope so!

For issue #2, if the default was `None`, then couldn't that be used as an implicit feature marker that you can't (incorrectly) rely on inheritance to percolate up the annotations of the superclass if the subclass happens to not define any annotations?

Currently Python never sets o.__annotations__ to None on any object.  So yes, assuming the user doesn't set it to None themselves, this would be new behavior.  If I understand your question correctly, yes, users could write new code that says

if o.__annotations__ is None:
    # great, we're in Python 3.10+ and no annotation was set on o!

Or they could just look at sys.version_info ;-)

Thanks for your feedback,