Refactor type related error raising into separate utility functions#7680
Conversation
…o correctly and efficiently handle the type name formatting.
|
Very superficial comment, but would it make more sense in Exceptions.c rather than Object handling.c |
Hmm, we already have a longer list of exception raising functions in |
|
The basic idea here definitely seems like an improvement to me, although I'm away from a proper computer at the moment so haven't had a detailed look. (Obviously there still looks to be one build issue though) |
I think I fixed the Limited API build problem, but the Py3.15 issue also applies to master and needs investigation. It seems that all End-to-End tests are failing since yesterday (2026-05-11) because they can't find distutils any more. The last setuptools release already dates a while back, and Py3.15b1 also isn't from exactly yesterday, so I can't see an obvious change that broke this. I'll try to dig into it. (EDIT: obviously, the Sanitizers jobs use the latest CPython main branch, so there might have been a change between 3.15b1 and now that broke this.) (EDIT2: I found python/cpython#149583 to be the most probable reason.) |
|
This PR branch is failing on CPython main in the same way as Cython master, and none of it is specific to either Py3.15 or this PR. So I deem this done and worth a second look. |
da-woods
left a comment
da-woods
left a comment
There was a problem hiding this comment.
Yes agree this cuts down some of the repetitive bits a lot.
I probably wouldn't have bothered with all different variations (just because I doubt that I'll remember that they all exist in future) but that's really just personal taste I think.
| #define __Pyx_RaiseTypeErrorWithObjectType(message, obj) __Pyx_RaiseTypeErrorWithType(message, Py_TYPE(obj)) | ||
| #define __Pyx_RaiseTypeErrorWithType(message, type_obj) __Pyx_RaiseErrorWithType(PyExc_TypeError, message, type_obj) |
There was a problem hiding this comment.
Definitely doesn't do any harm, but I probably wouldn't have bothered with these two macros (vs just passing TypeError to __Pyx_RaiseErrorWithType or __Pyx_RaiseErrorWithObjectType
There was a problem hiding this comment.
I considered it the "normal" case to raise a TypeError, thus the extra macros. But thanks for pointing at this, I found some that were really unnecessary in retrospect.
Mark the corresponding error handling functions as potentially unused.
2 participants
… to correctly and efficiently handle the type name formatting.
Closes #7601