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

[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.

[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.

[merwok]

More accurately: when an object’s class provides __annotate__, right?

[Zheaoli]

No, I think for now is right, consider the code following below

import annotationlib
class A():
    pass
a=A()
def demo(a):
    return {"annotate": 42}
a.__annotate__=demo
print(annotationlib.get_annotation(a))

[merwok]

That’s not how special methods work in Python.
There used to be a bug about that with the context manager protocol and __enter__, which was fixed.
There is an explicit exception for __class_getitem__ used to implement type hints like list[str] without needed a metaclass.
But otherwise dunder methods are looked up on the class of an object.

[Zheaoli]

Making sense. fixed

[merwok]

Well I was wrong. __annotate__ is not defined as a special method, but a data descriptor. It’s not looked up on the class.

[Zheaoli]

@JelleZijlstra PTAL when you got time

[merwok]

sorry, I had draft comment which were not submitted

[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]

@merwok Thanks for your time, PTAL when you got time

[JelleZijlstra]

This is a strange example; whether or not they are generic has no bearing on __annotate__.

[github-actions]

This PR is stale because it has been open for 30 days with no activity.