Repository navigation
AsyncMock force always creating an AsyncMock for child mocks #82303
Description
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/lisroach'
closed_at = None
created_at = <Date 2019-09-11.17:24:54.683>
labels = ['type-bug', 'library']
title = 'AsyncMock force always creating an AsyncMock for child mocks'
updated_at = <Date 2019-10-28.20:47:37.252>
user = 'https://github.com/lisroach'bugs.python.org fields:
activity = <Date 2019-10-28.20:47:37.252>
actor = 'pconnell'
assignee = 'lisroach'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2019-09-11.17:24:54.683>
creator = 'lisroach'
dependencies = []
files = []
hgrepos = []
issue_num = 38122
keywords = ['patch']
message_count = 4.0
messages = ['351991', '352000', '352101', '352360']
nosy_count = 7.0
nosy_names = ['cjw296', 'ezio.melotti', 'michael.foord', 'pconnell', 'matrixise', 'lisroach', 'xtreak']
pr_nums = ['16099', '16137']
priority = 'low'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue38122'
versions = []
Activity
lisroach commentedon Sep 11, 2019
This idea has been brought up in person before and also discussed on AsyncTest: Martiusweb/asynctest#100
It could be useful if someone has a lot of attributes that are also async that need to be mocked.
It could probably be done with a flag that gets passed on to _get_child_mock and overrides the if statement to always return an AsyncMock.
Looking mostly for if people think this is a good idea/bad idea and help see around any corners that may be there.
tirkarthi commentedon Sep 11, 2019
Sorry, is there an example of this use case. I went through the issue but have trouble understanding it since there are different suggestions. I guess child mock is always an AsyncMock irrespective of sync/async as I understand. We already had some reports over detecting async while patching to return AsyncMock and also had to document it to the users along with covering different ways of async functions.
voidspace commentedon Sep 12, 2019
That may change though, right?
In general I dislike the proliferation of keyword arguments if it's at all possible to avoid. I added way too many of them originally and the mock API is really big.
matrixise commentedon Sep 13, 2019
New changeset 14fd925 by Stéphane Wirtel (Michael Foord) in branch 'master':
bpo-38122: minor fixes to AsyncMock spec handling (GH-16099)
14fd925
serhiy-storchaka commentedon Sep 1, 2025
Currently the example from #82303 (comment) outputs:
which looks more reasonable. Do we still need an option that makes all attributes AsyncMock?
There are use cases for forcing this for certain attributes (when a sync method returns an Awaitable), but I think we can just patch the resulting AsyncMock object for that attribute (something like
m.foo = AsyncMock(Foo.foo)). That doesn't seem much more complicated than adding a special option to specify which attributes should be forced to use AsyncMock. And it's more flexible.