Thor Whalen <thorwha...@gmail.com> 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 against adding `__annotations__` etc. back when it was lacking. If there were clear use cases for having signature defaults be different from actual defaults, I'd also agree with the argument. If it were a complicated fix, I'd also agree with you. But it's a simple fix that would help avoiding unintended misalignments. I may be missing something, but the only positive reasons I see for keeping it the way it is are: (1) backcompatibility safety, and (2) not having to change the (in my opinion incorrect) tests. If it is kept as such, I think a documentation warning would go a long way in making users avoid the trap I myself fell into. On Wed, Aug 5, 2020 at 8:51 AM Dominic Davis-Foster <rep...@bugs.python.org> wrote: > > Dominic Davis-Foster <domi...@davis-foster.co.uk> 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 different types or that have different > default values. > > I can't think of a situation where you'd use wraps with a decorator that > doesn't take just *args and **kwargs. That's not to say there aren't > occasions where you'd want to to that, just that wraps isn't the right tool. > > ---------- > nosy: +domdfcoding > > _______________________________________ > Python tracker <rep...@bugs.python.org> > <https://bugs.python.org/issue41232> > _______________________________________ > ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue41232> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
