Graham Dumpleton <graham.dumple...@gmail.com> added the comment:
I am still working through this and thinking about implications, but my first impression is that the functools.partial object should provide an attribute (property) __signature__ which yields the correct result. When you think about it, any user who wants to implement a function wrapper using a class to do so rather than using functools.update_wrapper(), has to implement __signature__ if the wrapper is a signature changing decorator. So why shouldn't Python itself follow the same mechanism that is forced on users in their own wrappers. If functools.partial were to implement __signature__, then the part of PEP 362 where it says: > If the object is an instance of functools.partial, construct a new Signature > from its partial.func attribute, and account for already bound partial.args > and partial.kwargs becomes redundant as the code to deal with it is localised within the functools.partial implementation by virtue of __signature__ on that type rather than having a special case in inspect.signature(). If this was seen as making more sense, one might even argue that FunctionType and the bound variant could implement __signature__ and so localise things to those implementations as well, which would further simplify inspect.signature(). This would set a good precedent going forward that if any special callable wrapper objects are added to the Python core in the future, that they implement __signature__, rather than someone thinking that further special cases could be added to inspect.signature() to deal with them. I have yet to do some actual code experiments so might have more thoughts on the matter later. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue46761> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com