Improve exception reporting for problematic __set_name__ attributes #72401
Comments
|
As requested by Nick [0], this is a usability issue against CPython 3.6 to provide a better chained TypeError in this case: class _TokenType(tuple):
parent = None
def __getattr__(self, name):
new = _TokenType(self + (name,))
setattr(self, name, new)
new.parent = self
return new
Token = _TokenType()
Keyword = Token.Keyword
class KeywordCaseFilter(object):
ttype = KeywordTraceback (most recent call last):
File "test.py", line 14, in <module>
class KeywordCaseFilter(object):
TypeError: '_TokenType' object is not callableThe exception should report the specific object with the problematic __set_name__ attribute (rather than just passing along the underlying exception), as well as supporting __set_name__ = None to explicitly disable further lookup processing. Follow up to bpo-27366. |
timgraham
mannequin
added
3.7
|
The information we want to include in the chained exception:
The other idea I mentioned (allowing "__set_name__ = None" to prevent falling back to "__getattr__") needs a bit more consideration, as I don't quite recall where we're currently at in terms of expanding that idiom beyond "__hash__" and to the other one-shot ABCs. |
|
Maybe there is a bug in using __set_name__. Usually special methods are looked in class dict. But __set_name__ is looked in instance dict. This causes to invoking __getattr__. |
|
Proposed patch makes class creation code not looking up the __set_name__ attribute in instance dict. |
|
In any case I suggest to raise an AttributeError for dunder names in __getattr__ implementation. Otherwise you will encounter similar issue with pickling. |
|
I agree with Serhiy that __set_name__ should be looked up on the class like all other special methods. Pickle is a great example why lookup (of __reduce__) on the instance is a pain. |
|
Good catch Serhiy - I'd completely missed that in the original review, and definitely agree we should make that fix independently of the exception chaining idea. While that correction will fix the specific __getattr__ example given, we still have the problem of actual errors in looking up __set_name__ on the class (e.g. in a metaclass or in __getattribute__) and errors when calling it being hard to debug, as the traceback will point to the class header without giving the name of the offending attribute. |
|
New changeset 1a2b8398f045 by Serhiy Storchaka in branch '3.6': New changeset 2a5280db601c by Serhiy Storchaka in branch 'default': |
|
Now we need other reproducer for an exception. |
|
@Property can be used to define a broken __set_name__ attribute: >>> class BadIdea:
... @property
... def __set_name__(self):
... pass
...
>>> class NotGoingToWork:
... attr = BadIdea()
...
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'NoneType' object is not callableAnd there's also a failing __set_name__ call: >>> class FaultyImplementation:
... def __set_name__(self, *args):
... 1/0
...
>>> class TheoreticallyCouldWork:
... attr = FaultyImplementation()
...
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 3, in __set_name__
ZeroDivisionError: division by zero |
|
What error messages you want for these cases? |
|
The following seem like a reasonable starting point to me: TypeError: Failed to set name on 'BadIdea' instance 'attr' in 'NotGoingToWork': 'NoneType' object is not callable TypeError: Failed to set name on 'FaultyImplementation' instance 'attr' in 'TheoreticallyCouldWork': ZeroDivisionError: division by zero That is, the error message format would be along the lines of: |
|
Slight change, as it makes sense to reference the special method name explicitly: TypeError: Error calling __set_name__ on 'BadIdea' instance 'attr' in 'NotGoingToWork': 'NoneType' object is not callable TypeError: Error calling __set_name__ on 'FaultyImplementation' instance 'attr' in 'TheoreticallyCouldWork': ZeroDivisionError: division by zero |
|
Fixing the proposed format string accordingly, and also including the underlying exception type as I did in the examples: f"Error calling __set_name__ on {type(the_attr).__name__!r} instance {the_attr_name!r} in {class_being_defined.__name__!r}: {type(raised_exc).__name__}: {str(raised_exc)}" |
|
Shouldn't it be RuntimeError? Proposed patch makes RuntimeError be raised with chained original exception. This preserves more information. >>> class FaultyImplementation:
... def __set_name__(self, *args):
... 1/0
...
>>> class TheoreticallyCouldWork:
... attr = FaultyImplementation()
...
ZeroDivisionError: division by zero
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
RuntimeError: Error calling __set_name__ on 'FaultyImplementation' instance 'attr' in 'TheoreticallyCouldWork' |
|
Alternative patch chain original exception as __cause__ instead of __context__. What is better? >>> class FaultyImplementation:
... def __set_name__(self, *args):
... 1/0
...
>>> class TheoreticallyCouldWork:
... attr = FaultyImplementation()
...
ZeroDivisionError: division by zero
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
RuntimeError: Error calling __set_name__ on 'FaultyImplementation' instance 'attr' in 'TheoreticallyCouldWork' |
|
You're right, RuntimeError is a more suitable exception type. So +1 for the second version of the patch that uses |
|
Updated patch uses C API added in bpo-28410. It preserves the traceback of original exception: Traceback (most recent call last):
File "issue28214.py", line 3, in __set_name__
1/0
ZeroDivisionError: division by zero
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "issue28214.py", line 5, in <module>
class TheoreticallyCouldWork:
RuntimeError: Error calling __set_name__ on 'FaultyImplementation' instance 'attr' in 'TheoreticallyCouldWork' |
|
Serhiy, I don't find the _PyErr_FormatFromCause function in the code of CPython. Modules/_tracemalloc.o Modules/hashtable.o Modules/symtablemodule.o Modules/xxsubtype.o -lpthread -ldl -lutil -lm |
|
First apply the patch from bpo-28410. |
|
Serhiy, I have a failed test with test_capi. I have applied the patch from bpo-28410 and set_name_chain_error_cause_2.patch. stephane@sg1 ~/s/p/cpython> ./python -m test test_capi
Run tests sequentially
0:00:00 [1/1] test_capi
test test_capi failed -- Traceback (most recent call last):
File "/home/stephane/src/python/cpython/Lib/test/test_capi.py", line 221, in test_return_result_with_error
br'Fatal Python error: a function returned a '
AssertionError: Regex didn't match: b'Fatal Python error: a function returned a result with an error set\\nValueError\\n\\nDuring handling of the above exception, another exception occurred:\\n\\nSystemError: <built-in function return_result_with_error> returned a result with an error set\\n\\nCurrent thread.*:\\n File .*, line 6 in <module>' not found in b'Fatal Python error: a function returned a result with an error set\nValueError\n\nThe above exception was the direct cause of the following exception:\n\nSystemError: <built-in function return_result_with_error> returned a result with an error set\n\nCurrent thread 0x00007f5c560c3700 (most recent call first):\n File "<string>", line 6 in <module>'test_capi failed 1 test failed: Total duration: 6 sec |
|
Thank you for testing Stéphane. Ignore this failure, the test should be fixed by updated patch in bpo-28410. |
|
Serhiy, your patch works fine. |
|
New changeset f7e1e39ccddd by Serhiy Storchaka in branch '3.6': New changeset 7c3ec24f4582 by Serhiy Storchaka in branch 'default': |
Misc/NEWSso that it is managed by towncrier #552Note: 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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: