GeezerVison

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's never useful, it's 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__:

https://mail.python.org/archives/list/[email protected]/thread/AWKVI3NRCHKPIDPCJYGVLW4HBYTEOQYL/

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.

Happily, lazy-creating the annotations dict is an adequate fix, as long as the annotations dict is still stored in the object's __dict__. Code written using the old best practice, which peeks in the __dict__ for annotations on classes, will still see (or not see) the dict as it did before, so it will continue to work unchanged. (Lazy-creating the annotations dict doesn't actually fix the inherited annotations problem for such code--but this code is already working around the problem, so this is fine.) Going forward, code written for 3.10+ can always use getattr() to get the annotations dict from any object.

https://bugs.python.org/issue43901