On 4/18/21 9:10 AM, Damian Shaw wrote:
Hi Larry, all, I was thinking also of a compromise but a slightly
different approach:
Store annotations as a subclass of string but with the required frames
attached to evaluate them as though they were in their local context.
Then have a function "get_annotation_values" that knows how to
evaluate these string subclasses with the attached frames.
This would allow those who use runtime annotations to access local
scope like PEP 649, and allow those who use static type checking to
relax the syntax (as long as they don't try and evaluate the syntax at
runtime) as per PEP 563.
Something akin to this was proposed and discarded during the discussion
of PEP 563, although the idea there was to still use actual Python
bytecode instead of strings:
https://www.python.org/dev/peps/pep-0563/#keeping-the-ability-to-use-function-local-state-when-defining-annotations
It was rejected because it would be too expensive in terms of
resources. PEP 649's approach uses significantly fewer resources, which
is one of the reasons it seems viable.
Also, I don't see the benefit of requiring a function like
"get_annotation_values" to see the actual values. This would force
library code that examined annotations to change; I think it's better
that we preserve the behavior that "o.__annotations__" are real values.
Cheers,
//arry/
_______________________________________________
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/3CVZKZJZQ35PHA6P7U2ZZLOBTOS7V2AD/
Code of Conduct: http://python.org/psf/codeofconduct/
