-
-
Notifications
You must be signed in to change notification settings - Fork 30.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cleaning up generating macros in _cursesmodule.c
#125354
Conversation
518c817
to
adb6a33
Compare
adb6a33
to
6f84b18
Compare
The commit 6f84b18 is only for removing the If you want a separate PR, I can just cherry-pick that commit though it's easier to include it in this one to reduce the number of whitespace changes. |
I don't see the point of these changes, they don't solve any problem. They only look like coding style changes: -1 for me. |
Oh I should have given more context. I wanted to add the possibility to include the Python function name and the curses function name that were involved when we raise an exception. For now, it's a generic message saying that function X raised something, but the names may not necessarily match the C function that was actually called. What I wanted to do is essentially mimic OSError and its filename/filename2 attributes (that could help instead of parsing the message that we could change in the future). So I wanted first to cleanup the base code before continuing the work. If you think that the error feature is not needed, I'll just close this PR and the refactorization issue as well. |
Closing in favor of #125844. |
This is mostly a cosmetic but useful PR. Why? because it's for future maintenance. For now, all generated methods have the following signature (modulo the
Py_UNUSED
):and they are stored in
PyCursesWindow_methods
using(PyCFunction)
casts. I'm not sure whether we want to keep an explicit cast here or not but since we are also fixing UBSan failures, I think this one would count as one.Instead of changing it now, I first suggest cleaning up the macros and then, once we also fixed Argument Clinic generation, we may then fix the UBSan failures here as well (or I can patch half of the Window's object methods since the other half is AC-generated).
I don't see when we'll need to call a method directly using its implementation and not via the
PyObject_Call*
API so we can also patch the macros directly in this PR.@vstinner please tell me whether you want me to include the UBSan failure fix in this PR or not (for that reason, I will not put an issue number yet since I don't know whether it should be part of #123961 or #111178).