[issue41232] Python `functools.wraps` doesn't deal with defaults correctly

Thor Whalen added the comment: On the surface, seems like a fair design to me: Back-compatible yet solves this misalignment that bugged me (literally). It would also force the documentation of `functools.wraps` to mention this "trap", through describing the `signature_changed` flag. As for the

[issue41232] Python `functools.wraps` doesn't deal with defaults correctly

Jelle Zijlstra added the comment: We could add a new argument to `@functools.wraps()` to differentiate between a wrapper with the same signature and one with a different signature. Here's a possible design: * functools.wraps adds a new keyword-only argument signature_changed. It defaults to

[issue41232] Python `functools.wraps` doesn't deal with defaults correctly

Gregory P. Smith added the comment: That makes sense. It seems like we're missing information signature() would need to be able to differentiate between when it should default to follow .__wrapped__ vs when it shouldn't. Neither default can satisfy everyone. --

[issue41232] Python `functools.wraps` doesn't deal with defaults correctly

Jelle Zijlstra added the comment: That's because inspect.signature by default follows the `.__wrapped__` attribute, so it gives you the signature for the *wrapped* function. That behavior is occasionally problematic (I ran into it in the context of https://github.com/quora/pyanalyze/issues/8

[issue41232] Python `functools.wraps` doesn't deal with defaults correctly

Gregory P. Smith added the comment: Even if we shouldn't blindly propagate defaults (wrong in some wrapping scenarios), there is still a problem here as noted in Thor's opening message. A bug exists between functools.wraps and inspect.signature. The signature reported is wrong. why? -

[issue41232] Python `functools.wraps` doesn't deal with defaults correctly

Jelle Zijlstra added the comment: We should not do this, because the wrapping function may have different defaults, and updating __defaults__ would make it use the wrapped function's defaults. Example: >>> def f(y=1): ... print(y) ... >>> f() 1 >>> f.__defaults__ (1,) >>> f.__defaults_

[issue41232] Python `functools.wraps` doesn't deal with defaults correctly

Gregory P. Smith added the comment: I'm working on a more specialized case of this for functools.lru_cache in bpo-issue44003. But I believe this issue also makes sense. It is basically suggesting that __defaults__ and __kwdefaults__ should be included in the default set of assigned= attrib

[issue41232] Python `functools.wraps` doesn't deal with defaults correctly

Change by Caleb Donovick : -- nosy: +donovick ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.py

[issue41232] Python `functools.wraps` doesn't deal with defaults correctly

Terry J. Reedy added the comment: Thor, in the future, when you reply by email, snip off the messages you are replying to. When you your message is added to the webpage below the earlier message, the copy become extraneous noise. Quoting the hidden boilerplate on PRs is also useless. For

[issue41232] Python `functools.wraps` doesn't deal with defaults correctly

Thor Whalen added the comment: You are the guardians of the great python, so we can leave it at that if you want. That said for posterity, I'll offer a defense. The same "the tools does what it does, and if you need something else, use another tool" argument could have been applied to vote aga

[issue41232] Python `functools.wraps` doesn't deal with defaults correctly

Dominic Davis-Foster added the comment: To me your examples seem like a misuse of functools.wraps. IIUC its purpose is to make a wrapper that accepts solely *args and **kwargs appear to be the wrapped function; it doesn't seem to be intended to be used when the wrapper takes arguments of dif

[issue41232] Python `functools.wraps` doesn't deal with defaults correctly

Thor Whalen added the comment: Hi Terry, sorry for the later reply. Is this a bugfix? Well, I'm not sure what you would call a bug. Can't one always redefine a bug to be a feature, and visa versa? I would definitely say that the behavior (seeing one default in the signature, but a different o

[issue41232] Python `functools.wraps` doesn't deal with defaults correctly

Terry J. Reedy added the comment: Is this actually a bugfix? -- nosy: +terry.reedy versions: +Python 3.10 -Python 3.8 ___ Python tracker ___ __

[issue41232] Python `functools.wraps` doesn't deal with defaults correctly

Change by Raymond Hettinger : -- assignee: -> ncoghlan nosy: +ncoghlan ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

[issue41232] Python `functools.wraps` doesn't deal with defaults correctly

Thor Whalen added the comment: 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 `__kwdefault

[issue41232] Python `functools.wraps` doesn't deal with defaults correctly

Thor Whalen added the comment: Posted to stackoverflow to gather opinions about the issue: https://stackoverflow.com/questions/62782230/python-functools-wraps-doesnt-deal-with-defaults-correctly Also made GitHub PR: https://github.com/python/cpython/pull/21379 -- keywords: +patch mes

[issue41232] Python `functools.wraps` doesn't deal with defaults correctly

New submission from Thor Whalen : # PROBLEM When using `functools.wraps`, the signature claims one set of defaults, but the (wrapped) function uses the original (wrappee) defaults. Why might that be the desirable default? # PROPOSED SOLUTION Adding '__defaults__', '__kwdefaults__' to `WRAPP