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?