Agree that implementation I propose is trivial. I'm not sure what the benefit of overwriting a string literal in __annotations__ with the ForwardRef would be when it can be overwritten with the already evaluated value, hence why I was proposing the latter. On Thu, 2020-12-10 at 23:00 -0800, Guido van Rossum wrote:
That looks like a two-line convenience function using no private APIs, so you can easily include that in your own toolbox if you need it.
If your concern is that get_type_hints() is too slow, submit a PR that makes it faster. There's a cache built into ForwardRef, but it appears to be ineffective because a new ForwardRef instance is created each time when get_type_hints() encounters a string value. Maybe the ForwardRef instance should be stored back into `__annotations__`?
On Thu, Dec 10, 2020 at 10:43 PM Paul Bryan <pbryan@anode.ca> wrote:
With PEP 563 behavior going mainstream in Python 3.10, I see some ramifications, especially for runtime validation of type hints:
1. PEP 563 is changing the scope of evaluation of type hints, and in some cases it is not feasible to move that scope to the annotated object's globals. (I appreciate the reality that such cases would evade static type checkers.)
2. The typing.get_type_hints function causes annotation(s) to be evaluated from strings for every call, incurring a potentially significant runtime penalty depending on how often type hints are evaluated at runtime.
To address both of these issues, I'm proposing that a new function be added to typing: affix_type_hints.
I'm thinking something like this:
def affix_type_hints(obj, globalns=None, localns=None): """ Affixes an object's type hints to the object.
Type hints are affixed by first being resolved through get_type_hints, then by storing the result in the object's __annotations__ attribute.
If the object is a class, this function will affix annotations from all superclasses. """
if hints := typing.get_type_hints(obj, globalns, localns, include_extras=True): obj.__annotations__ = hints
Advantages:
1. The time and scope of type hint affixation are under the control of the caller. Future references can be realized before type hints are affixed. If there is a novel local scope required to resolve the type hint, it can be supplied in-context; future calls to get_type_hints inherit the benefit of such pre-resolution.
2. Annotations will not be re-evaluated on repeated calls to get_type_hints.
3. It doesn't require a change to the behavior of the get_type_hints function.
Disadvantages:
1. Subclasses inheriting superclass annotations may be undesirable.
2. Monkey-patching __annotations__ may be considered an anti- pattern.
3. Maybe allowing re-evaluation on every get_type_hints call is desirable? (I'd rather avoid the potential for side-effects.)
4. The cited example is a 2-line function; perhaps its triviality makes it unjustified to add to the stdlib.
Alternatives:
1. A caching version of get_type_hints. It looks like ForwardRef.__forward_value__ could actually deliver if annotations were encoded as ForwardRef objects instead of string literals. Am I missing a way for ForwardRef to cache evaluated values when get_type_hints is called?
2. Something I haven't considered? Please let me know.
Paul _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/GZ7QGE...
Code of Conduct: http://python.org/psf/codeofconduct/