richcompare suppresses all errors raised from descriptors of comparison special methods
还没有人认领这个 Issue。
- 主要语言
- Python
- 星标
- 77.2k
- 派生
- 35.9k
- PR 合并指标
- PR 指标待抓取
描述
Bug report
Bug description:
This is reporting possibly incorrect suppression of all errors generated by descriptors for the comparison special methods __eq__, __lt__, etc. (and possibly some other special methods). This only affects errors during the __get__ stage, while errors from the actual call propagate as expected.
I say possibly incorrect because I can see this being one of those sensitive underbellies that could affect existing behavior for some libraries. However, this seems inconsistent relative to some other special methods like __contains__, __bool__, etc., and since it suppresses all errors like SystemExit, MemoryError, KeyboardInterrupt, etc. it can hide underlying problems or behaviors that are hard to diagnose.
Minimal example
Minimal demonstration of the issue below is a descriptor which always raises an exception during __get__. The result of comparison through == returns False instead of raising the error. The type of error raised from __get__ is not important, it could have been from exit() or anything else down the stack. However, other special methods like __bool__ do raise the exception, as does directly accessing __eq__ as a method.
class BadDescriptor:
def __get__(self, obj, cls=None):
assert False
class BadBase:
__eq__ = BadDescriptor()
__bool__ = BadDescriptor()
b = BadBase()
print(f"{b == 1=}")
print(f"{b.__eq__(1)=}")
b == 1=False
Traceback (most recent call last):
File "bad_descriptor.py", line 24, in <module>
print(f"{b.__eq__(1)=}")
^^^^^^^^
File "bad_descriptor.py", line 14, in __get__
assert False
^^^^^
AssertionError
Suspected cause and proposed resolution
The source of this behavior appears to be in Objects/typeobject.c function slot_tp_richcompare. Currently if an error occurs while getting the comparison method from a descriptor the error is cleared and NotImplemented is returned. Looking at some of the other special methods it seems like there is some inconsistency, some check for PyErr_Occurred and propagate the exception (EG slot_nb_bool), while others clear the error and default to some other action (E.G. slot_tp_repr).
if (func == NULL) {
PyErr_Clear();
Py_RETURN_NOTIMPLEMENTED;
}
A couple experimental resolutions were attempted to look at the consequence. The first was to treat errors similar to slot_nb_bool, propagating them instead of suppressing.
if (func == NULL) {
if(PyErr_Occurred()){
return NULL;
}
Py_RETURN_NOTIMPLEMENTED;
}
However, this caused a failed test which seems to be checking that raising AttributeError should lead to suppression and default comparison. It is not clear to me if that actually should be the expected behavior, and the comment in the test seems to indicate that it may actually be testing for some internal regression:
======================================================================
ERROR: testForExceptionsRaisedInInstanceGetattr2 (test.test_class.ClassTests.testForExceptionsRaisedInInstanceGetattr2)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/cdodd/proj/contrib/cpython/Lib/test/test_class.py", line 592, in testForExceptionsRaisedInInstanceGetattr2
E() == E() # In debug mode, caused a C-level assert() to fail
^^^^^^^^^^
File "/home/cdodd/proj/contrib/cpython/Lib/test/test_class.py", line 580, in booh
raise AttributeError("booh")
AttributeError: booh
But, as a compromise the following alternative checking specifically for AttributeError passes all tests enabled for my current platform. Depending on feedback here I am willing to contribute a pull request once I have a better idea as to what is expected/desired in these cases.
if (func == NULL) {
PyObject* exc = PyErr_Occurred();
if (exc != NULL){
if (PyErr_GivenExceptionMatches(exc, PyExc_AttributeError)){
// NOTE: suppresses only "attribute" errors
PyErr_Clear();
}else{
return NULL;
}
}
Py_RETURN_NOTIMPLEMENTED;
}
CPython versions tested on:
3.14, CPython main branch
Operating systems tested on:
Linux
Linked PRs
- gh-131187
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
调研方向
从 Objects/typeobject.c 和 slot_tp_richcompare 开始,然后阅读 test/test_class.py,尤其是 testForExceptionsRaisedInInstanceGetattr2 及其 booh helper。查看关联的 PR gh-131187,并确定在比较查找期间应如何处理描述符错误;完成的标准是行为已确定且相关测试套件通过。
由索引模型根据 Issue 内容生成。
评估
- 技术栈
- c, python
- 领域
- compilers
- Issue 类型
- 缺陷
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 活跃度
- 停滞
- 描述清晰度
- 基本清楚
- 新手友好度
- 30/100