
Thanks Larry, This seems to be going in a good direction. I do note another motivator -- folks don't want annotations to hurt run-time performance, particularly when they are being used primarily for pre-run-time static type checking. Which makes sense. And PEP 649 seems to affect perfromance. Which brings me to: On Sun, Apr 18, 2021 at 9:24 AM Richard Levasseur <richardlev@gmail.com> wrote:
Java deals with this problem by making its annotations compile-time only
unless you mark them to be kept at runtime)
Maybe we could borrow that as well -- annotations could be marked to not be used at run time at all. That could be the default.
2. It's my belief that the *vast *majority of annotations are unused at runtime, so all the extra effort in resolving an annotation expression is just wasted cycles. It makes sense for the default behavior to be "string annotations", with runtime-evaluation/retention enabled when needed.
exactly. And I would prefer that the specification as to whether this was a "stringified" or not annotation at the annotation level, rather than at the module level. It's quite conceivable that a user might want to use "run time" annotations, in say, the specification of a Pydantic class, and annotations just for type checking elsewhere in the module. and then would we need the
"o.__str_annotations__"
attribute? or even PEP 649 at all? What you'd end up with is __annotations__ potentially containing both objects and strings that could be type objects -- which currently works fine:
In [20]: class A: ...: x: "int" ...: y: int ...: In [21]: A.__annotations__ Out[21]: {'x': 'int', 'y': int} In [22]: typing.get_type_hints(A) Out[22]: {'x': int, 'y': int} Then the only thing that would change with PEP 563 is the default behaviour. If I'm not mistaken, the complexity (and performance hit) of dealing with the whole could be string, could be object, evaluate the string process would be in the type checkers, where performance is much less of an issue. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython