I've hit a conceptual snag in this.

What I thought I needed to do: set __annotations__= {} in the module dict, and set __annotations__= {} in user class dicts.  The latter was more delicate than the former but I think I figured out a good spot for both.  I have this much working, including fixing the test suite.

But now I realize (*head-slap* here): if *every* class is going to have annotations, does that mean builtin classes too?  StructSequence classes like float?  Bare-metal type objects like complex?  Heck, what about type itself?!

My knee-jerk initial response: yes, those too.  Which means adding a new getsetdef to the type object.  But that's slightly complicated.  The point of doing this is to preserve the existing best-practice of peeking in the class dict for __annotations__, to avoid inheriting it.  If I'm to preserve that, the get/set for __annotations__ on a type object would need to get/set it on tp_dict if tp_dict was not NULL, and use internal storage somewhere if there is no tp_dict.

It's worth noticing that builtin types don't currently have __annotations__ set, and you can't set them.  (Or, at least, float, complex, and type didn't have them set, and wouldn't let me set annotations on them.)  So presumably people using current best practice--peek in the class dict--aren't having problems.

So I now suspect that my knee-jerk answer is wrong.  Am I going too far down the rabbit hole?  Should I just make the change for user classes and leave builtin classes untouched?  What do you think?

Cheers,

/arry