gh-91002: Support __annotate__ for functools.partial and functools.partialmethod

[Zheaoli]

• Issue: functools.partial objects should set __signature__ and _annotations__ #91002

---

📚 Documentation preview 📚: https://cpython-previews--139753.org.readthedocs.build/

[JelleZijlstra]

Could this instead be implemented with a custom __annotate__ function on partial objects, so annotationlib itself doesn't need to change?

[bedevere-app]

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

[Zheaoli]

Could this instead be implemented with a custom __annotate__ function on partial objects, so annotationlib itself doesn't need to change?

Hi @JelleZijlstra , thank you for your time.
From my personal perspective, I would actually prefer to make the modifications in the partial C module, as this would allow us to obtain the most original information. However, I have some concerns:

Currently, the partial C API doesn't have the relevant interfaces reserved. Adding them would be relatively more complex than the Python version.
If we add the information from functools, we may need to synchronously modify the inspect library to avoid circular dependencies (note: inspect has special handling for functools.partial).

In short, if we solve this problem from functools, it would indeed be the optimal choice in terms of effect, but it would increase complexity.
Do you think this PR needs to open a discussion on discuss.python.org?

[JelleZijlstra]

I'd strongly prefer if this is done in functools, not annotationlib. This sets a good example where objects can support annotation introspection themselves through overriding __annotate__, instead of through special cases in annotationlib itself.

To make the implementation simpler, we can make the C code delegate to Python code, similar to how typevarobject.c invokes the Python typing module in some cases. So partial would gain an __annotate__ descriptor implemented in C, but that descriptor would just invoke some Python code.

[Zheaoli]

To make the implementation simpler, we can make the C code delegate to Python code, similar to how typevarobject.c

Nice, this is better than my original thought. I'll make a try

[merwok]

With the new implementation, I’m not sure how much annotationlib docs should mention support for partial. Maybe mention the generic support and link to a new section in functools doc with the info here?

[Zheaoli]

Yes! I have updated the docs

[merwok]

Are these three examples the only special cases handled, or is this paragraph saying that __wrapped__ attributes are followed to unwrap wrappers?

[Zheaoli]

I have updated the docs, PTAL

[Zheaoli]

I have made the requested changes; please review again

[bedevere-app]

Thanks for making the requested changes!

@JelleZijlstra: please review the changes made to this pull request.

[JelleZijlstra]

I feel like this doesn't belong in the annotationlib docs, maybe in the functools ones.

[Zheaoli]

I have a different idea here. plz correct me if I'm wrong

It seems that we recommend people use annotationlib to process the annotation here. I prefer add a more detail document in here and reference this in functools

[Zheaoli]

@JelleZijlstra I have updated the PR, PTAL