Here is the issue:

$ cat example.py
import functools # I am using Python 2.5

def identity_dec(func):
    def wrapper(*args, **kw):
        return func(*args, **kw)
    return functools.update_wrapper(wrapper, func)

@identity_dec
def example(): 
    pass

>>> import inspect
>>> from example import example
>>> print inspect.getsource(example)
    def wrapper(*args, **kw):
        return func(*args, **kw)

You get the source code of the closure
and not what would be more meaningful, i.e.
the string

"""
@identity_dec
def example():
pass
"""

Of course one could argue that this is not a bug
(in a sense the inspect module is doing the right
thing) but still it is giving information which
is not very useful.

Looking at the guts of inspect.getsource, one discovers the origin
of the problem: inspect.findsource is looking at the attribute
.co_firstlineno of the decorated function code object.
Unfortunately .co_firstlineno is a read-only attribute, otherwise
it would be possibile to change functools.update_wrapper to set it to
the correct line number (i.e. the line where
the undecorated function is defined, -1). So
I don't think you can fix this in current
Python, but it is something to keep in mind for Python 2.6 and 3.0. It should also manage classmethods/
staticmethods and other decorators not implemented
as closures.

I'm setting the target to 2.6 and 3.0. Maybe somebody can come up with a
sensible patch.

Rather than devising something specific to the co_firstlineno attribute,
why not have functools.update_wrapper add a "wrapped_func" attribute
pointing to the original function object? That way, each function
inspecting the decorated function would have the opportunity to walk the
decoration chain if it wants.

I am attaching a patch that address this issue.

I did not test the patch, but if it really addresses the issue, I don't see why such a simple fix would not be applied.

Guilherme,

Can you add unit tests? Also, the second chunk in your patch is just a style fix which is a distraction for reviewers.

I don't think this patch is correct, because we don't know if the closure[0] is the wrapped function, consider the following case:

def fun():
    abc = 1
    def fun2():
        print(abc)
    print(inspect.getsource(fun2))

In this case, the __closure__ of fun2 is [cell(1), ], the patch doesn't work.

I think the behavior of inspect.getsource(arg) is no problem because it indeed gives the right source code of arg, no matter arg is a wrapper function or an original function. michele argues that the result is not meaningful, through in most case it seems reasonably because wrapper functions usually do litter valuable work, but it is not correct for all cases. What if a wrapper function does more valuable work than the wrapped function? In this case should getsouce() give the source code of wrapper function because it's more meaningful? The concept "wrapper" and "wrapped" should have no relation with its source code.

I suggest you assign a special named attribute of all wrapper functions to its wrapped function yourself, something like "wrapped_function", and then you can walk through the wrapper chain to find the real source you want for each wrapper function. Then the stdard library's update_wrapper() and getsource() can remain unchanged.

Hello. Attached patch which uses the new inspect.unwrap, added in http://hg.python.org/cpython/rev/2aa6c1e35b8a.

New changeset ad9cc6124a19 by Yury Selivanov in branch 'default':
inspect: Fix getsource() to support decorated functions.
https://hg.python.org/cpython/rev/ad9cc6124a19

Thanks for the bug report and patch! Committed to 3.5.

This now leaves inspect.getsource inconsistent with inspect.getsourcefile:

>> import inspect
>> from contextlib import contextmanager

>>> @contextmanager
... def func():
...    yield

>>> inspect.getsource(func)
'@contextmanager\ndef func():\n    yield\n'
>>>inspect.getsourcefile(func)
'C:\\Program Files\\Python 3.5\\lib\\contextlib.py'

Should getsourcefile be changed to match?

This is causing numpy/numpy#11639, but it's not clear if this is a bug or by design.

Should getsourcefile be changed to match?

I'd say yes. There's no point in getsourcefile returning the file location of the topmost decorator. Feel free to open a new issue and submit a PR to fix this!

New issue opened at https://bugs.python.org/issue34305, along with a PR linked there.