Description

lisroach

opened on Sep 11, 2019

Issue body actions

BPO	38122
Nosy	@cjw296, @ezio-melotti, @voidspace, @phmc, @matrixise, @lisroach, @tirkarthi
PRs	bpo-38122: minor fixes to AsyncMock spec handling #16099 [3.8] bpo-38122: minor fixes to AsyncMock spec handling (GH-16099). #16137

^{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

1. lisroach commented on Sep 11, 2019

   

   lisroach

   on Sep 11, 2019

   ContributorAuthor

   More actions

   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.
2. lisroach

   self-assigned this

   on Sep 11, 2019
3. lisroach

   added

   stdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory

   type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

   on Sep 11, 2019
4. tirkarthi commented on Sep 11, 2019

   

   tirkarthi

   on Sep 11, 2019

   Member

   More actions

   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.

   from unittest.mock import AsyncMock
   
   
   class Foo:
   
       def foo(self):
           pass
   
       async def bar(self):
           pass
   
   m = AsyncMock(Foo)
   f = m()
   print(m.foo)
   print(m.bar)

   $ python3.8 /tmp/bar.py
   <AsyncMock name='mock.foo' id='4313089744'>
   <AsyncMock name='mock.bar' id='4313395696'>
   sys:1: RuntimeWarning: coroutine 'AsyncMockMixin._mock_call' was never awaited
5. voidspace commented on Sep 12, 2019

   

   voidspace

   on Sep 12, 2019

   Contributor

   More actions

   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.
6. matrixise commented on Sep 13, 2019

   

   matrixise

   on Sep 13, 2019

   Member

   More actions

   New changeset 14fd925 by Stéphane Wirtel (Michael Foord) in branch 'master':
   bpo-38122: minor fixes to AsyncMock spec handling (GH-16099)
   14fd925
7. ezio-melotti

   transferred this issue fromon Apr 10, 2022
8. serhiy-storchaka

   added this to Unittest & doctest issueson May 20, 2022
9. serhiy-storchaka commented on Sep 1, 2025

   

   serhiy-storchaka

   on Sep 1, 2025

   Member

   More actions

   Currently the example from #82303 (comment) outputs:

   <MagicMock name='mock.foo' id='140189304493312'>
   <AsyncMock name='mock.bar' id='140189304494720'>
   

   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.

Issue actions