This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: asyncio.coroutine fails if asyncio debug mode is enabled and wrapped function don't have "__name__" attribute
Type: Stage:
Components: asyncio Versions: Python 3.4
process
Status: closed Resolution: duplicate
Dependencies: Superseder:
Assigned To: Nosy List: gvanrossum, vrutsky, vstinner, yselivanov
Priority: normal Keywords:

Created on 2015-11-17 12:47 by vrutsky, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (3)
msg254800 - (view) Author: Vladimir Rutsky (vrutsky) * Date: 2015-11-17 12:47
In Python 3.4.3 with enabled asyncio debug a function is
wrapped using the following code in @asyncio.coroutine:

@functools.wraps(func)
def wrapper(*args, **kwds):
    w = CoroWrapper(coro(*args, **kwds), func)
    if w._source_traceback:
        del w._source_traceback[-1]
    w.__name__ = func.__name__
    if hasattr(func, '__qualname__'):
        w.__qualname__ = func.__qualname__
    w.__doc__ = func.__doc__
    return w

The unconditional access to "__name__" and "__doc__" attributes may fail in some circumstances.

As this case looks strange and unrealistic I met it in a real
application that used mocking in tests. The code there was something like the following:

def f():
    return "f result"

mocked_f = Mock(wraps=f)
coro_func = asyncio.coroutine(mocked_f)
print(loop.run_until_complete(coro_func()))
mocked_f.assert_called_once_with() 

Here is complete example:
https://gist.github.com/rutsky/65cee7728135b05d49c3

This issue is fixed in 95964:957478e95b26 changeset during adding support of async/await syntax, so it is not reproduced in Python 3.5 or 3.4 head, but still reproducible in latest released version of Python 3.4 branch: 3.4.3.

So until 3.4.4 is released this issue still may be considered as not fixed.
msg254807 - (view) Author: Yury Selivanov (yselivanov) * (Python committer) Date: 2015-11-17 17:32
> So until 3.4.4 is released this issue still may be considered as not fixed.

Since this issue is fixed in the repo, and will be shipped in the upcoming 3.5.1 and 3.4.4, I'd suggest to close this issue -- there is nothing to be done here.
msg254808 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2015-11-17 17:41
Fixed in repo is good enough to close an issue.
History
Date User Action Args
2022-04-11 14:58:23adminsetgithub: 69834
2015-11-17 17:41:18gvanrossumsetstatus: open -> closed
resolution: duplicate
messages: + msg254808
2015-11-17 17:32:23yselivanovsetmessages: + msg254807
2015-11-17 12:47:20vrutskycreate