Support `typing.get_type_hints(partial(fn, ...))` by 'unwrapping' the `partial`, and discarding hints for bound arguments

[Zac-HD]

We added this to Hypothesis' get_type_hints() helper a few years ago, and while most of that function is clearly not suitable to upstream, it struck me recently that "works with functools.partial" could quite reasonably be added to the stdlib function.

It's also plausible that the typing module prefers to avoid calling inspect.signature, though I don't have a great sense of how to determine which parameters have been bound without getting the signature of the partial object. In any case, the implementation need not be the same as in Hypothesis, although as the author you're welcome to use that code if you'd like.

[sobolevn]

Maybe we should instead add __annotations__ / __annotate__ to partial?

Now:

>>> import functools
>>> def a(x: int, y: str) -> bool: ...
... 
>>> functools.partial(a, 1).__annotations__
Traceback (most recent call last):
  File "<python-input-3>", line 1, in <module>
    functools.partial(a, 1).__annotations__
AttributeError: 'functools.partial' object has no attribute '__annotations__'

Proposed:

>>> import functools
>>> def a(x: int, y: str) -> bool: ...
... 
>>> functools.partial(a, 1)
functools.partial(<function a at 0x200014f4610>, 1)
>>> functools.partial(a, 1).__annotations__
{'y': str, 'return': bool}

🤔

I can see several problems around this, however. For example: partial has both python and C implementations. It would not be easy to use inspect.signature in C code. It also can be rather hard to calculate the correct final signature without calling .bind.

[JelleZijlstra]

I'm not excited about adding yet more complexity to typing.get_type_hints; I think it already makes a number of questionable decisions and part of me would rather want to deprecate it.