Author ncoghlan
Recipients ncoghlan
Date 2011-10-26.06:43:10
SpamBayes Score 6.7335e-14
Marked as misclassified No
Message-id <>
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.
Date User Action Args
2011-10-26 06:43:11ncoghlansetrecipients: + ncoghlan
2011-10-26 06:43:11ncoghlansetmessageid: <>
2011-10-26 06:43:11ncoghlanlinkissue13266 messages
2011-10-26 06:43:10ncoghlancreate