backporting inspect.unwrap

[rbtcollins]

http://bugs.python.org/issue23764 highlighted that one of the useful features inspect.signature offers over the old APIs is correctly following wrapper chains.

Python 3.4 split that feature out into an independently usable component: https://docs.python.org/3/library/inspect.html#inspect.unwrap

There are some other features potentially worth backporting from 3.4 (like the inspect.signature based inspect.getargspec and inspect.getfullargspec), so a full rebase may even be worthwhile.

From aliles#12, filed by @ncoghlan

[rbtcollins]

I need to check whether VM or stdlib changes were needed to make that possible - there's a defect in handling of decorated functions affecting mock today (see #13) - but once we get on top of that, sounds good. Patches and/or help to do so welcomed :).

[ncoghlan]

For inspect.unwrap specifically, note that there was a longstanding bug in functools.wraps where it inadvertently overwrote wraps by copying it from the wrapped function. That was fixed in 3.4 at the same time that inspect.unwrap was introduced: https://docs.python.org/dev/whatsnew/3.4.html#changes-in-the-python-api

If funcsigs backports it, then it's likely worth revisiting the question of fixing the behaviour of functools.wraps in 2.7.

[rbtcollins]

We revisited on the list, and @ncoghlan is now against it :). Colour me confused - that said, we can offer a patch() helper to fixup wraps (actually the update helper, wraps is just a partial application) - though that will only help things imported after the patch is applied.

[ncoghlan]

I thought I'd added the __wrapped__ feature to update_wrapper in both 2.7 & 3.2, but I was misremembering - it turns out I only added it to 3.2.

Thus my change of tune came about by way of actually checking the current 2.7 behaviour this time, rather than assuming it was the same as 3.x as I had previously.