GeezerVison

Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept this contribution by verifying everyone involved has signed the PSF contributor agreement (CLA).

CLA Missing

Our records indicate the following people have not signed the CLA:

@FFY00

For legal reasons we need all the people listed to sign the CLA before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

If you have recently signed the CLA, please wait at least one business day
before our records are updated.

You can check yourself to see if the CLA has been received.

Thanks again for the contribution, we look forward to reviewing it!

@rhettinger next, when we call get_type_hints we rely on an undocumented behavior of order of __annotations__/get_type_hints. Is this correct or am I missing anything? Should I open a bug?

Friendly ping, it has been 5 months.

@FFY00, have you considered using the inspect module to find the name of the first argument, and then checking for that in __annotations__?

@taleinat thanks for the attention!

I have, as pointed out in bpo. The issue is getting the correct first argument. This decorator operates before the method is registered in the class, so we don't know if we should skip the first argument (self) or not.

This PR only fixes the issue of return annotation being used in the dispatch signature, it only mitigates the main problem. I am not sure how to properly address the root issue here.

@FFY00

The issue is getting the correct first argument. This decorator operates before the method is registered in the class, so we don't know if we should skip the first argument (self) or not.

To my understanding, we have separate singledispatch and singledispatchmethod decorators, and singledispatchmethod "magically" takes care of the "self" arg. I haven't dug too deep into the intricacies of that code, though.

Have you tried this with singledispatchmethod and seen a problem with the above mentioned approach? If so, please provide some details.

This PR only fixes the issue of return annotation being used in the dispatch signature, it only mitigates the main problem. I am not sure how to properly address the root issue here.

We really should solve the root issue. I don't think avoiding only using the return annotation, while still possibly using the annotation for another argument, is a reasonable fix, unless we've made a significant attempt at a thorough fix and have come to the conclusion that it would be unreasonably hard to do, or that it would break backwards-compatibility too harshly.

@FFY00

@taleinat thanks for the attention!

Thank you for working on this, and sorry for the great delay in giving this any attention!

To my understanding, we have separate singledispatch and singledispatchmethod decorators, and singledispatchmethod "magically" takes care of the "self" arg. I haven't dug too deep into the intricacies of that code, though.

Ah, sorry. I forgot about this 🙃

To solve this issue I added a _arg_index argument to register, which defaults to 0 and we set it to 1 when called via singledispatchmethod. I am not too happy about this, as it exposes a new argument. Let me know if you can think of a better way 😊

Friendly ping.

just an extra comment: Unfortunately, we can't rely on isinstance(method, types.MethodType), which would have more cleanly solved the issue.

My apologies, @FFY00, I simply haven't been able to find the time to follow this up.

@ambv, could you perhaps take a look at this?

I synchronized the branch with main, but it seems that this solution is not compatible with other features added in recent years, so some existing tests now fail.

Closing in face of that. I'll leave it for someone else to take up.

To my understanding, we have separate singledispatch and singledispatchmethod decorators, and singledispatchmethod "magically" takes care of the "self" arg. I haven't dug too deep into the intricacies of that code, though.

It doesn't: #130827