This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author larry
Recipients larry
Date 2021-04-21.06:44:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
The behavior of the __annotations__ member is wildly different between the three objects (function, class, module) that support it.  Many of these differences are minor, but one in particular has been an awful wart for years: classes can inherit __annotations__ from their base classes.  This is incontestably a misfire of the original design--it is never useful, it is only confusing, and libraries who examine annotations have had to work around it for years.

I started a thread in January 2021 in which I brought up this and other inconsistencies with respect to __annotations_:

The reaction was positive: yes, that's a genuine problem, and there's an easy, highly compatible fix that everybody liked: classes should always have an __annotations__ dict set.  So that the behavior is consistent, modules should always have one set too.

This won't be a large change.  However, there are a lot of changes flying around with respect to __annotations__ right now.  My plan is to get the work ready, then when the dust is mostly-settled I'll get it updated, reviewed, and merged.  Definitely before Python 3.10b1.

Long term, I'd like to get the other changes to annotations I proposed in that thread:
  * del o.__annotations__ always raises an exception.
  * o.__annotations__ is permitted to be None.
  * You can only set o.__annotations__ to either a dict or None.
But it's probably best to not change everything all at once.
Date User Action Args
2021-04-21 06:44:01larrysetrecipients: + larry
2021-04-21 06:44:01larrysetmessageid: <>
2021-04-21 06:44:01larrylinkissue43901 messages
2021-04-21 06:44:00larrycreate