Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept this contribution by verifying everyone involved has signed the PSF contributor agreement (CLA).

Recognized GitHub username

We couldn't find a bugs.python.org (b.p.o) account corresponding to the following GitHub usernames:

@thorwhalen

This might be simply due to a missing "GitHub Name" entry in one's b.p.o account settings. This is necessary for legal reasons before we can look at this contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

You can check yourself to see if the CLA has been received.

Thanks again for the contribution, we look forward to reviewing it!

Further, note that even with the additional 'defaults', and 'kwdefaults', functools.wraps breaks when keyword only arguments involved:

from functools import wraps, WRAPPER_ASSIGNMENTS, partial

# First, I need to add `__defaults__` and `__kwdefaults__` to wraps, because they don't come for free...
my_wraps = partial(wraps, assigned=(list(WRAPPER_ASSIGNMENTS) + ['__defaults__', '__kwdefaults__']))

def g(a: float, b=10):
    return a * b

def f(a: int,  *, b=1):
    return a * b

# all is well (for now)...
assert f(3) == 3
assert g(3) == 30

This:

my_wraps(g)(f)(3)

raises TypeError (missing required positional argument 'b'), expected

Note that wraps(g)(f)(3) doesn't throw a TypeError, but the output is not consistent with the signature (inspect.signature(wraps(g)(f)) is (a: float, b=10), so 3 should be multiplied by 10). This is because defaults wasn't updated.

See for example, that third-party from boltons.funcutils import wraps works as expected. And so do (the very popular) wrapt and decorator packages.

Note that the boltons version works for wraps(f)(g), but not wraps(g)(f) in my example.

See: https://stackoverflow.com/questions/62782709/pythons-functools-wraps-breaks-when-keyword-only-arguments-involved

Tests are failing, so I had a look at them, and my conclusion is that the tests are the mistake here.
Please see if you agree.

I'm usint python 3.82 on a Mac.

The tests fail here:

# In test/test_inspect.py:849
def test_argspec_api_ignores_wrapped(self):
    # Issue 20684: low level introspection API must ignore __wrapped__
    @functools.wraps(mod.spam)
    def ham(x, y):
        pass
    # Basic check
    self.assertArgSpecEquals(ham, ['x', 'y'], formatted='(x, y)')  # <--- this what fails

Note that mod.spam is this:

def spam(a, /, b, c, d=3, e=4, f=5, *g, **h):
    eggs(b + d, c + f)

The assertArgSpecEquals fails on the comparison of expected and actual defaults (line 776):

self.assertEqual(defaults, defaults_e)

where defaults_e == None and defaults == (3,), but neither seem to be correct. In my opinion,
the correct value should be ham.__defaults__ == spam.__defaults__ == (3, 4, 5).

In the current version of functools.wraps, __defaults__ and __kwdefaults__ are not even copied, which leads to defaults_e == defaults == ham.__defaults__ == None, so the test passes. In my opinion, it shouldn't.

Here are two code blocks that may help you to investigate:

# With the current functools.py
# WRAPPER_ASSIGNMENTS = ('__module__', '__name__', '__qualname__', '__doc__',
#                        '__annotations__', '__defaults__', '__kwdefaults__')

import inspect
import functools
from test import inspect_fodder as mod

@functools.wraps(mod.spam)
def ham(x, y):
    pass

assert ham.__defaults__ == None == inspect.getargspec(ham).defaults 

# With proposed change, adding '__defaults__', '__kwdefaults__' to WRAPPER_ASSIGNMENTS:
# WRAPPER_ASSIGNMENTS = ('__module__', '__name__', '__qualname__', '__doc__',
#                        '__annotations__', '__defaults__', '__kwdefaults__')


import inspect
import functools
from test import inspect_fodder as mod

@functools.wraps(mod.spam)
def ham(x, y):
    pass

assert ham.__defaults__ == (3, 4, 5)
assert inspect.getargspec(ham).defaults == (3,)

@thorwhalen, please sign the CLA. Thank you!

@thorwhalen Reminding you what csabella said

Where do I find this?

Please read the message posted by @the-knights-who-say-ni above. Not only you need to sign the CLA, you'll also need to create an account on the bug tracker, and associate your GitHub username there.

This PR is stale because it has been open for 30 days with no activity. If the CLA is not signed within 14 days, it will be closed. See also https://devguide.python.org/pullrequest/#licensing

Closing this stale PR because the CLA is still not signed.