I think there is a point to be made for requiring a function call to resolve annotations, in regard to the ongoing discussion about relaxing the annotation syntax (https://mail.python.org/archives/list/python-dev@python.org/message/2F5PVC5M...) Type annotation are still a fast moving topic compared to python as a whole. Should the annotation syntax be relaxed and annotations be stored as strings then requiring a function call to resolve annotations would allow third party libraries, be it typing_extensions or something else, to backport new type annotation syntax by offering their own version of "get_annotated_values". Typing features are already regularly backported using typing_extensions and this could not be done for new typing syntax unless annotations are stored as strings and resolved by a function. Note: Obviously new typing syntax couldn't be backported to versions before the typing syntax was relaxed, unless explicitly wrapped in a string, but I would imagine that if we see a relaxed annotation syntax we might see new typing syntax every now and then after that. Adrian Freund On April 18, 2021 6:49:59 PM GMT+02:00, Larry Hastings <larry@hastings.org> wrote:
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-functio...
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/