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

[Irit Katriel]

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'

--
nosy: +iritkatriel
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ryan Gonzalez]

Changes by Ryan Gonzalez :


--
nosy: +Ryan.Gonzalez

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Steven Barker]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

See also issue4322.

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Nick Coghlan]

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 let's narrow the scope of this particular issue to just that, and defer the 
idea of a new public API for the time being.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Robert Collins]

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) Add a new API. Either narrow (add the parameter) or big (add a struct). 
Pros: everyone treated equally. Cons: More API surface area, and more complex 
calling convention.

c) use symbol versioning to change the existing API. Cons: more complex 
build-time detection for users. Pros: API surface area held constant.

d) Don't fix it. :)

I don't have a particular preference, though the struct thing is a wash IMO - 
it saves adding a serial to the API, at the cost of having a versioned 
datastructure which needs an embedded serial number. [Except perhaps that you 
can use symbol versioning to deal with evolutions of the struct - but thats 
fairly complex to carry off well, and I think this would be the first example 
w/in Python].

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Nick Coghlan]

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 runtime function name:

>>> g(1)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: g() takes 0 positional arguments but 1 was given

In this case though, I think that's arguably a problem, as we probably want 
error messages (unlike tracebacks) to include the "intended for human 
consumption" name, but they currently don't, they expose the name of the 
wrapper function if it's actually constraining its arguments rather than 
passing them through for subsequent validation:

>>> def make_wrapper(f):
... @functools.wraps(f)
... def wrapper():
... return f()
... return wrapper
... 
>>> @make_wrapper
... def g():
... return f()
... 
>>> g(1)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: wrapper() takes 0 positional arguments but 1 was given

That makes me more inclined towards a solution like Daniil's patch, but the 
growing signature of PyEval_Code* still bothers me. Perhaps we could collect 
the various runtime state arguments up into a "PyEvalScope" struct and make the 
new API PyEval_EvalCodeInScope(PyObject *code, PyObject *scope)?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Nick Coghlan]

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.g. through the use of functools.wraps).

However, that also highlights why we need to use the compile time qualname in 
the traceback, rather than the runtime one: because we currently use the 
compile time name from the code object rather than the runtime name from the 
function.

A test case to demonstrate that:

>>> def f():
... 1/0
... 
>>> import functools
>>> @functools.wraps(f)
... def g():
... return f()
... 
>>> g()
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 3, in g
  File "", line 2, in f
ZeroDivisionError: division by zero
>>> g.__qualname__
'f'
>>> g.__name__
'f'

Note that "g" still appears in the relevant traceback line, even though both 
__name__ and __qualname__ have been updated to refer to "f". For a traceback we 
want to know where the source of the function actually lives, not where it 
claims to be from for human introspection purposes.

As far as the comparison to __module__ goes, I think that's a different case - 
we couldn't add that to the code object even if we wanted to, because the 
compiler doesn't know the module name, it only knows the file name. It's also 
possible to take an already compiled python file, move it to a different 
directory, and have the module name change due to the new location in the 
package hierarchy. __qualname__ is different as, like __name__, it's entirely 
local to the module and hence available to the compiler at compile time.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Martin Panter]

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 have class names, if they're methods

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com