bpo-39082: Fix: AsyncMock is unable to correctly patch static/class methods

[czardoz]

Essentially, patching a coroutinefunction decorated with @classmethod or @staticmethod does not currently work correctly. Instead of creating an AsyncMock(), patch() uses a Mock(), which fails when it's awaited on.

https://bugs.python.org/issue39082

[the-knights-who-say-ni]

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:

@czardoz

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!

[lisroach]

I think this implementation is good, I am wondering if @tirkarthi's suggestion of:

if hasattr(obj, '__func__'):
     obj = getattr(obj, '__func__')

wouldn't be better, as it might cover more use cases. It might have the potential of helping out with the backwards compatibility issue with 3.6 in testing-cabal/mock#476. What do you think Karthikeyan?

[cjw296]

@czardoz - please can you add a NEWS entry for this?

[tirkarthi]

I would prefer accessing function from __func__ only for classmethod and staticmethod to keep the scope limited as per the report. I must admit that I found __func__ having the correct function while debugging initially as there is difference in the attribute lookup precedence. I don't think this will have compatibility issue with 3.6. Am I missing something here?

[cjw296]

@czardoz - can you add a NEWS entry for this please, I'd like to merge it :-)

[cjw296]

Wrong way round, closing this in favour of #18116.

[cjw296]

@tirkarthi - I think I'm fine with the __func__ check, where would you see this causing problems?

[tirkarthi]

I was just concerned if I was missing any other internals having __func__ where it will be used with the other PR and hence the suggestion to use this only for classmethod/staticmethod as in this PR. Our test suite would have caught if any change in behavior :)