`inspect` does not correctly handle over-length `__defaults__` for functions

[zahlman]

Bug report

Bug description:

This is largely a re-report of #81244 which I believe was inappropriately dismissed. This is a bug because it causes functions to be incorrectly documented and understood. For example, it breaks pydoc and therefore the built-in help.

Python explicitly allows for the __defaults__ of a function to be re-assigned. Presumably this was for a reason. Having modified a function this way, it would make sense to have an accurate signature for the result.

However, consider the output of the following (3.8+; requires modification for far-EOL versions):

import inspect

def example(a, b, /, c, d): return (a, b, c, d)

for count in range(10):
    example.__defaults__ = tuple(range(count))
    signature = inspect.signature(example)
    result = example(*'abcd'[:max(0, 4-count)])
    print(f'with {count} defaults: {signature=!s:23}, {result=}')

We get:

with 0 defaults: signature=(a, b, /, c, d)        , result=('a', 'b', 'c', 'd')
with 1 defaults: signature=(a, b, /, c, d=0)      , result=('a', 'b', 'c', 0)
with 2 defaults: signature=(a, b, /, c=0, d=1)    , result=('a', 'b', 0, 1)
with 3 defaults: signature=(a, b=0, /, c=1, d=2)  , result=('a', 0, 1, 2)
with 4 defaults: signature=(a=0, b=1, /, c=2, d=3), result=(0, 1, 2, 3)
with 5 defaults: signature=(a, b, /, c, d=0)      , result=(1, 2, 3, 4)
with 6 defaults: signature=(a, b, /, c=0, d=1)    , result=(2, 3, 4, 5)
with 7 defaults: signature=(a, b=0, /, c=1, d=2)  , result=(3, 4, 5, 6)
with 8 defaults: signature=(a=0, b=1, /, c=2, d=3), result=(4, 5, 6, 7)
with 9 defaults: signature=(a=0, b=1, /, c=2, d=3), result=(5, 6, 7, 8)

As can be seen, when there are more __defaults__ than parameters, inspect's logic for pairing default values with parameters differs from what the runtime does. With up to 2N values it behaves as though the last N were missing; with even more, it behaves as if all but the first N were missing. Whereas the runtime consistently uses the last N values of the tuple. There is no distinction between positional-only and positional-or-keyword arguments.

Consequently, help(example) shows an incorrect signature as well. In my testing, there has been an issue with help used this way since 3.4, though it works correctly in 2.7 and 3.3.

If this is not deemed a bug in inspect's logic (why does it not simply have access to the interpreter's logic?), then there is a problem with the runtime. Arguably, it should reject attempts to set __defaults__ to an over-long tuple, since its actual behaviour (taking only the last N values) is not unambiguously the right way to handle it. "In the face of ambiguity, refuse the temptation to guess."

N.B. From further testing, it appears that inspect.signature is still mistaken in 3.3 (the version where it was added), but the builtin help() still works, even though pydoc still imports inspect. Presumably a legacy method was used to compute the signature for help output, which was then changed in 3.4.

CPython versions tested on:

3.3 (pydoc/help() works but inspect.signature does not), 3.4 .. 3.14 inclusive (not working)

(pydoc/help() works in 2.7; unclear if/how inspect is involved)

Operating systems tested on:

Linux (but most likely platform-agnostic)

[serhiy-storchaka]

A function that has more default values than positional parameters is invalid. The behavior of invalid function is not defined. Just do not create such functions.

[bswck]

This is a bug because it causes functions to be incorrectly documented and understood.

I wouldn't agree. If the documentation is correct when __defaults__ is correct, then what causes functions to be incorrectly documented/understood is the invalid value of __defaults__; not something else. I'd argue that __defaults__ of length larger than function's parameter count is incorrect, despite runtime not covering this case. There do exist various validation rules for some predictable unhappy paths. For instance, it is validated during attribute assignment that __defaults__ is a tuple.

In this particular case, the OP of the precedent issue noted (in #81244 (comment)):

In every day usage, for "normal" functions, generated by the compiler from "normal", hand-typed source code, it is impossible to encounter this.

@ZeroIntensity (mentorship): suggested label: pending

[bswck]

On the other hand, there has been some prior work to support incorrect __defaults__: #105840

[bswck]

I've been thinking about adding some extra notes in the docs here, but overall, they seem to be enough in this regard:

A tuple containing default parameter values for those parameters that have defaults, or None if no parameters have a default value.

This closes __defaults__ in context of the parameters of the function, logically disallowing __defaults__ of length larger than function's parameter count (extra values can't be matched to any existing parameters). Consequently, __defaults__ of length larger than function parameter count is incorrect => it's a UB.

[zahlman]

Consequently, __defaults__ of length larger than function parameter count is incorrect => it's a UB.

My thinking is that a language as high-level as Python should not knowingly incorporate UB. So I would then say the over-long __defaults__ should be rejected at assignment time.

[ZeroIntensity]

I'm almost certain that someone is unknowingly doing that somewhere and just isn't seeing the consequences. We don't want to break them.

[bswck]

Consequently, __defaults__ of length larger than function parameter count is incorrect => it's a UB.

My thinking is that a language as high-level as Python should not knowingly incorporate UB. So I would then say the over-long __defaults__ should be rejected at assignment time.

I see where you're coming from. What about opening a discussion at https://discuss.python.org about it? You are likely to get some insightful views there that would help with assessing whether this is or isn't a good idea. I've done this myself a few times and it's pretty nice!

[serhiy-storchaka]

Condition len(func.__defaults__) <= func.__code__.co_argcount should be true.

The problem is that you can change both __defaults__ and __code__, in arbitrary order. If you only add check in the __defaults__ setter, you can still get invalid function after setting __code__ with small co_argcount. If you add checks in both setters, you can break someone's code. Their can first set large __defaults__ before setting __code__ or they can set __code__ with small co_argcount before setting small __defaults__ -- both cases can be now broken. You can workaround this by first setting __defaults__ to None, then set __code__ and __defaults__, in that order, to their final values. Anyway, this will require rewriting the user code. If __defaults__ and co_argcount depend on the user input, such special case may not be caught in tests.

We can add checks. But only after assessing whether the benefit outweighs the cost of rewriting the user code and the cost of possible bugs.