I faced this particular issue by writing decorators for asyncio coroutines. I even posted a question to SO:http://stackoverflow.com/questions/23015626/how-to-decorate-an-asyncio-coroutine-to-retain-its-nameHowever, since that I realized the problem is more general. I believe that a generator object should inherit its function's __name__ attribute instead of ignoring it. Example:################################################################import functoolsdef decorated(genfunc):    @functools.wraps(genfunc)    def wrapper(*args, **kargs):        print('inside wrapper')        for x in genfunc(*args, **kargs):            yield 'decorated: {!r}'.format(x)    print('outside wrapper')    print('wrapper.__name__: {!r}'.format(wrapper.__name__))    return wrapper@decorateddef simple_genfunc():    """Testdoc."""    yield from range(10)if __name__ == '__main__':    print('simple_genfunc.__name__: {!r}'.format(        simple_genfunc.__name__))    print('simple_genfunc().__name__: {!r}'.format(        simple_genfunc().__name__))################################################################And its result:Z:\>python -i genfuncdec.pyoutside wrapperwrapper.__name__: 'simple_genfunc'simple_genfunc.__name__: 'simple_genfunc'simple_genfunc().__name__: 'wrapper'>>> simple_genfunc<function simple_genfunc at 0x00C30420>>>> simple_genfunc.__wrapped__<function simple_genfunc at 0x00C304B0>>>> simple_genfunc()<generator object wrapper at 0x00C0EE18>>>> simple_genfunc.__wrapped__()<generator object simple_genfunc at 0x00C0ED28>As you can see the generator object's __name__ remained the hardcoded one.

I think this is a specific case of a more general need to improve 'wraps' that was discussed on python-dev not too long ago.

gen_qualname.patch: add a new "__qualname__" attribute to generators and change how the name is set: use the name of the function, instead of using the name of the code.Incompatible changes of this patch:- repr(generator) now shows the qualified name instead of the name- generator name comes from the function name which may be differentIf the function has a name different than the code (if the function name was changed, for example by @functools.wraps), the generator now gets the name from the function, no more from the code object. IMO it's the expected behaviour, and it's more useful.I'm writing on email to python-dev to discuss these changes.

Discussion on python-dev:https://mail.python.org/pipermail/python-dev/2014-June/135026.html

@Antoine: Can you please review gen_qualname.patch?

Your patch doesn't have a "review" link. Perhaps it should be regenerated against updated default?

Updated patch, rebased on the default branch. I add a minor unit test (modify also gen.__name__).

Updated patch: names must now be strings and cannot be deleted; make _PyEval_EvalCodeWithName private.

New changesetaa85e8d729ae by Victor Stinner in branch 'default':Issue#21205: Add a new ``__qualname__`` attribute to generator, the qualifiedhttp://hg.python.org/cpython/rev/aa85e8d729ae

Ok, this issue is now fixed in Python 3.5.For Python 2.7 and 3.4, it may be possible to change how the generator name is set (from the function, not from the code object). It might break the backward compatibility, even if I don't think that anyone rely on the exact name of the generator, and the function name is more useful than the code name.What do you think for Python 2.7 and 3.4: would you be ok to change also the generator name? I can write a patch which adds a new gi_name but the name would not be modifiable to limit the incompatible changes.

New changeset901a8265511a by Victor Stinner in branch 'default':Issue#21205: Fix unit testshttp://hg.python.org/cpython/rev/901a8265511a

New changeset28b3b8b22654 by Victor Stinner in branch 'default':Issue#21205: Complete the "versionchanged" note in inspect documentationhttp://hg.python.org/cpython/rev/28b3b8b22654

Le 16/06/2014 10:20, STINNER Victor a écrit :>> What do you think for Python 2.7 and 3.4: would you be ok to changealso the generator name? I can write a patch which adds a new gi_namebut the name would not be modifiable to limit the incompatible changes.I don't think it is worthwhile.

Antoine Pitrou wrote:> I don't think it is worthwhile.Ok, let's keep the issue closed then ;-)Thanks for the review Antoine.