This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: inspect.signature bind doesn't include defaults or empty tuple/dicts
Type: behavior Stage: test needed
Components: Versions: Python 3.4, Python 3.5
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: r.david.murray, rmccampbell7, yselivanov
Priority: normal Keywords:

Created on 2014-06-07 05:10 by rmccampbell7, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (7)
msg219916 - (view) Author: Ryan McCampbell (rmccampbell7) Date: 2014-06-07 05:10
I'm not sure if this is really a bug, but it is unexpected behavior. When you call "bind" on a Python 3.3 signature object, if you omit an optional argument, the default is not provided in the arguments dict. Similarly, if there is a "var positional" or "var keyword" parameter but there are no extra arguments, it will not be included. To emulate the effect on the namespace of an actual function, I would expect these to be included, as an empty tuple/dict in the case of variable arguments. I realize the current behavior may be useful in some cases, but if so, then another method could be added: bind_full, which would include all parameters of the signature.
msg220552 - (view) Author: Ryan McCampbell (rmccampbell7) Date: 2014-06-14 13:49
If this is decided against, a partial solution would be to set the "default" attribute of VAR_POSITIONAL and VAR_KEYWORD args to an empty tuple/dict, respectively. Then you could get a parameter's value no matter what with boundargs.get(, param.default).
msg221104 - (view) Author: Yury Selivanov (yselivanov) * (Python committer) Date: 2014-06-20 18:21
That's the intended and documented behaviour, see

You can easily implement the functionality you need by iterating through Signature.parameters and copying defaults to the BoundArguments.arguments mapping. There is no need to complicate the API with a dedicated method for that (if anything, in 3.5 you can subclass Signature and use from_callable to have any functionality you want).

Closing this one as 'not a bug'.
msg221197 - (view) Author: Ryan McCampbell (rmccampbell7) Date: 2014-06-21 20:14
Copying defaults still doesn't give you var positional/keyword arguments, which means, you have to explicitly check the parameter type, and then add them in. I still think it would more useful to have an "official" way of getting all function parameters from arguments.
msg221367 - (view) Author: Yury Selivanov (yselivanov) * (Python committer) Date: 2014-06-23 17:05
Can you explain the use case for it? What's the problem you're trying to solve?
msg221524 - (view) Author: Ryan McCampbell (rmccampbell7) Date: 2014-06-25 04:57
It's not really a particular use case. I was making a function decorator for automatic type checking using annotations (ironically I discovered later there is an almost identical example in the PEP for signatures). But I can't think of any use case when it would be undesirable to include the extra parameters, unless it slows down the code, hence the possibility of a separate method. It would not complicate the API to add behavior that would simplify most applications. And I just realized this is also the behavior of inspect.getcallargs, for which the docs recommend to switch to Signature.bind.
msg221558 - (view) Author: Yury Selivanov (yselivanov) * (Python committer) Date: 2014-06-25 17:03
> But I can't think of any use case when it would be undesirable to include the extra parameters

One use case is that you are actually loosing information what arguments Signature.bind() was called with, when defaults are included. In some cases this information is important.

> hence the possibility of a separate method

Since it's relatively easy to add mix defaults in, I'd prefer to be conservative here, and wait for a stronger community interest before adding a new method to API.

But thanks for the bug report. If you find any other use cases for a separate method, please feel free to update this issue.
Date User Action Args
2022-04-11 14:58:04adminsetgithub: 65883
2014-06-25 17:03:34yselivanovsetmessages: + msg221558
2014-06-25 04:57:42rmccampbell7setmessages: + msg221524
2014-06-23 17:05:59yselivanovsetmessages: + msg221367
2014-06-21 20:14:52rmccampbell7setmessages: + msg221197
2014-06-20 18:21:51yselivanovsetstatus: open -> closed
resolution: not a bug
messages: + msg221104
2014-06-14 13:49:17rmccampbell7setmessages: + msg220552
2014-06-13 17:44:05terry.reedysetstage: test needed
versions: + Python 3.5, - Python 3.3
2014-06-07 13:06:57r.david.murraysetnosy: + r.david.murray
2014-06-07 07:44:44berker.peksagsetnosy: + yselivanov
2014-06-07 05:10:48rmccampbell7create