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/2F5PVC5MOWMGFVOX6FUQOUC7EJEEXFN3/)
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 <la...@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-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/N74BWTHGBWWR46EB3TVLZZDJXTMHSIP2/ Code of Conduct: http://python.org/psf/codeofconduct/
