[New-bugs-announce] [issue13266] Support for unwrapping __wrapped__ functions in 'inspect' module
report at bugs.python.org
Wed Oct 26 08:43:11 CEST 2011
New submission from Nick Coghlan <ncoghlan at gmail.com>:
I just got bitten by the singularly unhelpful results of doing inspect.getsource(generator_context_manager).
Now that @functools.wraps adds the __wrapped__ attribute, perhaps inspect.getsource(f) should follow the wrapper chain by default?
This would affect other inspect APIs as well, such as getgeneratorstate() and the new getclosurevars() and getgeneratorlocals() that will be available in 3.3
While the source code of the wrapper could still be accessed by doing inspect.getsource(f.__code__), this isn't a reliable alternative in general (e.g. it doesn't work when introspecting closure state, since that needs access to the function object to look things up correctly). Accordingly, there would need to be a way to disable the "follow wrapper chains behaviour".
Alternatively (and more simply), we could just add an "inspect.unwrap(f)" function that followed a chain of __wrapped__ attributes and returned the last object in the chain (using an "already seen" set to avoid hit the recursion limit if someone sets up a wrapper loop). Applying this would then be a manual process when the initial output of an inspect function is clearly coming from a wrapper rather than the underlying function definition.
components: Library (Lib)
title: Support for unwrapping __wrapped__ functions in 'inspect' module
versions: Python 3.3
Python tracker <report at bugs.python.org>
More information about the New-bugs-announce