On 24. 04. 21 9:52, Larry Hastings wrote:
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?
Beware of adding mutable state to bulit-in (C static) type objects:
these are shared across interpreters, so changing them can “pollute”
unwanted contexts.
This has been so for a long time [0]. There are some subinterpreter
efforts underway that might eventually lead to making __annotations__ on
static types easier to add, but while you're certainly welcome to
explore the neighboring rabbit hole as well, I do think you're going in
too far for now :)
[0]
https://mail.python.org/archives/list/python-dev@python.org/message/KLCZIA6FSDY3S34U7A72CPSBYSOMGZG3/
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/3GIZO2R2IRIN47THXRWAZKEQ5JBFRITP/
Code of Conduct: http://python.org/psf/codeofconduct/
