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 <richard...@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
_______________________________________________
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/PWHUB4YULJ33KF7HNMTLDPVK6W2RPW7V/
Code of Conduct: http://python.org/psf/codeofconduct/
