Incorrect application of func.__defaults__ by inspect's signature APIs

[mr-nfamous]

BPO	37063
Nosy	@1st1, @mr-nfamous, @isidentical

^{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 = None
created_at = <Date 2019-05-27.10:57:38.225>
labels = ['3.7', '3.8', 'type-bug', 'library']
title = "Incorrect application of func.__defaults__ by inspect's signature APIs"
updated_at = <Date 2019-11-24.15:36:38.678>
user = 'https://github.com/mr-nfamous'

bugs.python.org fields:

activity = <Date 2019-11-24.15:36:38.678>
actor = 'BTaskaya'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2019-05-27.10:57:38.225>
creator = 'bup'
dependencies = []
files = []
hgrepos = []
issue_num = 37063
keywords = []
message_count = 2.0
messages = ['343613', '357397']
nosy_count = 3.0
nosy_names = ['yselivanov', 'bup', 'BTaskaya']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue37063'
versions = ['Python 3.7', 'Python 3.8']

[mr-nfamous]

The interpreter matches the values in func.__defaults__ with the calculated positional argument names "right-to-left", while inspect does does so "left-to-right". In every day usage, for "normal" functions, generated by the compiler from "normal", hand-typed source code, it is impossible to encounter this.

>>> def f(x): return x
>>> x.__defaults__ = (1,2,3)
>>> inspect.getfullargspec(f)
FullArgSpec(args=['x'], varargs=None, varkw=None, defaults=(1,), kwonlyargs=[], kwonlydefaults=None, annotations={})
>>> f()
3
>>> f.__defaults__
(1, 2, 3)

So I'll be honest: I've submitted this particularly inconsequential bug report as a pretext to ask for advice on how to contribute here, because frankly, this is getting out of hand. While I haven't counted, it would not surprise me if I have more than 20 open tickets on here currently. While that may not be uncommon it does bother me slightly. And those are just the ones I had the time and/or remembered to to submit a ticket for. There's another 45-50 whose location I'm certain of, fully documented and fixed.

If this little digression is against some sort of rules, then I apologize now and must concur. That being said, despite my lack of a formal education, my seemingly never-ending quest to push the interpreter to its limits, hunting for the most esoteric of optimizations (and flaws) has turned out to be quite the hobby. I've aquired a great deal of knowledge on the subject which, in the grand scheme of things is being wasted, as the only thing of actual significance I could see myself doing with it is using it to contribute here.

But when I consider the amount of time I've wasted on the matter already on this, I've totally lost faith in my own ability to judge what might constitute a good resource on the subject of GH. The other venues I'm aware of haven't been helpful to me so I don't even bother with them anymore. I will read the dev guide again, since it has been a while. However to my recollection the problems I had with it wasn't technicality per se, it was that it was it was full of totally foreign terminology to me, with words and phrases such as "pulling on this while the squisher of that squasher pushes on that".

[isidentical]

As mentioned in docs, getfullargspec is based on signature() and signature objects doesnt keep record of all defaults. It tries to map defaults with parameters but if you have less default then total parameter amount it will discard rest of defaults. IMHO this isn't a bug.

[iritkatriel]

I agree with @isidentical .

[hugovk]

This has been re-opened in #140380.