When using the @property decorator the wrapped functions are not exposed for source introspection. (At least I can't see how they are.)

The issue is then that Ipython "%psource" will show the source for the @property as opposed to the function that it wraps.

By implementing the __wrapped__ attribute you can set the wrapped function to fget and then the source for that function can me identified for source introspection.

I perform this hack in code to overcome this issue.

class qproperty(property):
    # Fix for ipython ? and ?? (%pdef, %psource)
    # Omitting the class doc string prevents ipython from showing the
    # doctoring for the property builtin class; I suspect this is a
    # bug.
    def __init__(self, fget=None, fset=None, fdel=None, doc=None):
        super(qproperty, self).__init__(fget, fset, fdel, doc)
        self.__wrapped__ = fget

# Overwrite property with qproperty so that in the future this hack might
# be easily removed.
property = qproperty

This is related to issue #5982.

> When using the @property decorator the wrapped functions 
> are not exposed for source introspection. 
> (At least I can't see how they are.)

The underlying functions are already exposed as the "fget", "fset", and "fdel" attributes of property objects.

Here is an example of how to access the source:

class Dog:
    @property
    def age(self):
        return 42

if __name__ == '__main__':
    import inspect
    age_property = Dog.__dict__['age']
    lines, size = inspect.getsourcelines(age_property.fget)
    print(''.join(lines))

__wrapped__ is specifically for the case where the outer function is a relatively straightforward wrapper around the inner one (i.e. those cases where it would be appropriate to use functools.wraps or Graham Dumpleton's more sophisticated wrapt module).

More complex decorators and descriptors (like property) will define their own mechanism for accessing the internal details.