[issue2786] Names in function call exception should have class names, if they're methods

Irit Katriel added the comment: This seems to have been fixed by now, on 3.11 I get this: >>> class foo: ... def __init__(self, bar): ... pass ... >>> foo() Traceback (most recent call last): File "", line 1, in TypeError: foo.__init__() missing 1 required positional argument: 'bar'

[issue2786] Names in function call exception should have class names, if they're methods

Changes by Ryan Gonzalez : -- nosy: +Ryan.Gonzalez ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.

[issue2786] Names in function call exception should have class names, if they're methods

Steven Barker added the comment: A few weeks ago I reported issue 27389 which looks to be a duplicate of this issue. Has any progress been made on this issue? -- nosy: +Steven.Barker ___ Python tracker

[issue2786] Names in function call exception should have class names, if they're methods

Serhiy Storchaka added the comment: See also issue4322. -- nosy: +serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing

[issue2786] Names in function call exception should have class names, if they're methods

Nick Coghlan added the comment: I think a) is worth doing regardless - in many cases, third party libraries will be dealing with function, generator or coroutine objects, rather than with code objects directly, so they'll benefit even if the updated API remains private to the interpreter. So

[issue2786] Names in function call exception should have class names, if they're methods

Robert Collins added the comment: Here are some options. a) Don't make the new thing public - instead export within Python.exe the existing private symbol _...withNames. Pros: no change to public API. Cons: extension modules using the public API cannot make these sorts of errors clearer. b)

[issue2786] Names in function call exception should have class names, if they're methods

Nick Coghlan added the comment: Hmm, I'd made the same mistake Martin did - I was looking at the tracebacks moreso than at the exception message itself. Looking at the argument unpacking exception message in the context of the test case above, that also uses __code__.co_name rather than the ru

[issue2786] Names in function call exception should have class names, if they're methods

Nick Coghlan added the comment: With __qualname__ being mutable, I agree that adding __code__.co_qualname wouldn't be a substitute for that. Instead, similar to the relationship between __name__ and __code__.co_name, they would start out the same, but the function attribute may change later (e

[issue2786] Names in function call exception should have class names, if they're methods

Martin Panter added the comment: Note to self: this is about changing the name in an exception message, not in the back-trace of call sites that triggered an exception :) -- title: Names in traceback should have class names, if they're methods -> Names in function call exception should