inspect.signature bind doesn't include defaults or empty tuple/dicts

[rmccampbell7]

BPO	21684
Nosy	@bitdancer, @1st1

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2014-06-20.18:21:51.692>
created_at = <Date 2014-06-07.05:10:48.104>
labels = ['type-bug', 'invalid']
title = "inspect.signature bind doesn't include defaults or empty tuple/dicts"
updated_at = <Date 2014-06-25.17:03:34.536>
user = 'https://bugs.python.org/rmccampbell7'

bugs.python.org fields:

activity = <Date 2014-06-25.17:03:34.536>
actor = 'yselivanov'
assignee = 'none'
closed = True
closed_date = <Date 2014-06-20.18:21:51.692>
closer = 'yselivanov'
components = []
creation = <Date 2014-06-07.05:10:48.104>
creator = 'rmccampbell7'
dependencies = []
files = []
hgrepos = []
issue_num = 21684
keywords = []
message_count = 7.0
messages = ['219916', '220552', '221104', '221197', '221367', '221524', '221558']
nosy_count = 3.0
nosy_names = ['r.david.murray', 'yselivanov', 'rmccampbell7']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'test needed'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue21684'
versions = ['Python 3.4', 'Python 3.5']

[rmccampbell7]

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.

[rmccampbell7]

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.name, param.default).

[1st1]

That's the intended and documented behaviour, see https://docs.python.org/3/library/inspect.html#inspect.BoundArguments.arguments.

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'.

[rmccampbell7]

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.

[1st1]

Ryan,
Can you explain the use case for it? What's the problem you're trying to solve?

[rmccampbell7]

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.

[1st1]

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.