Larry Hastings <[email protected]> added the comment:
Hmm. Sorry for the stream-of-consciousness thought process here, but this
approach adds wrinkles too.
Function objects from the very beginning have lazy-created their annotations
dict if it's not set. Which means this works fine:
while True:
del fn.__annotations__
print(fn.__annotations__)
You can do that all day. The function object will *always* create a new
annotations object if it doesn't have one. del fn.__annotations__ always
works, and accessing fn.__annotations__ always succeeds. It doesn't retain any
state of "I already lazily created one, I shouldn't create another".
If I add getsets to classes and modules so they lazy-create annotations on
demand if they otherwise aren't set, then either a) they need an extra bit set
somewhere that says "I lazily created an empty annotations dict once, I
shouldn't do it again", or b) they will duplicate this behavior that functions
display.
a) would better emulate existing semantics; b) would definitely be a
user-visible breaking change. There's actually a test in the
Lib/test/test_opcodes (iirc) that explicitly tests deleting __annotations__,
then checks that modifying the annotations dict throws an exception. I haven't
done any investigating to see if this check was the result of a regression, and
there was a bpo issue, and there was a valid use case, etc etc etc.
My instinct is that deleting o.__annotations__ is not an important or
widely-used use case. In fact I plan to recommend against it in my "best
practices" documentation. So either approach should be acceptable. Which
means I should go with the simpler one, the one that will duplicate the
function object's always-recreate-annotations-dicts behavior.
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue43901>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
