Larry Hastings <la...@hastings.org> added the comment: When I proposed this new function, stringized annotations were the default behavior in Python 3.10, and there were two calls to typing.get_type_hints() in the standard library:
* inspect.signature() * functools.singledispatch() Now that stringized annotations are no longer the default in 3.10, we've reverted that change to inspect.signature(). The call is still present in functools.singledispatch(), but that's been there for a while--it's in 3.9.4 for example. It's worth considering changing inspect.signature() to use get_annotations(). To be honest, I've never been really sure if the idea of PEP 563 stringized annotations are supposed to be a hidden implementation detail, or a first-class concept that the user (and the standard library) is expected to deal with. My current get_annotations() implementation assumes the former, and eval()s the annotations back into real Python values if it thinks that's the right thing to do. Personally I'd prefer that inspect.signature() un-stringized annotations for me--I would see that as a useful feature--but I could be completely wrong on this. For now, I'm going to plan on modifying inspect.signature() so it calls get_annotations() as part of this PR. (I'll also modify inspect.signature() to take a "eval_str" keyword-only parameter, and pass that through to get_annotations(). That gives the caller control over this un-stringizing feature, in case they need to turn it off.) Łukasz: what about functools.singledispatch()? IIUC, it uses typing.get_type_hints() to get the type of the first parameter of a function, so it can use that as an index into a dict mapping first-argument types to functions.. Since it's not a user-visible detail perhaps it doesn't matter. But it seems a little strange to me that it's using typing.get_type_hints()--ISTM it should be calling inspect.signature(), or possibly this proposed new inspect.get_annotations(). What do you think? ---------- nosy: +lukasz.langa _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue43817> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
