GeezerVison is showing github.com — Improve error messages of `curses` by indicating failed C function · Issue #125843 · python/cpython
Improve error messages of curses by indicating failed C function #125843DescriptionFeature or enhancement
Proposal:
The curses module raises an exception curses.error with a message of the form "XXX() returned ERR" where XXX is generally the name of the C or Python function that was just called. Most of the time, XXX and the Python function that was called have the same name and XXX is a real curses C function or macro. However, in some cases, this is not the case and the actual curses function that was called has a different name.
For debugging purposes, I suggest adding an attribute to the exception class, say .funcname which holds the name of the macro / function that was called at runtime in the C code. This will help users debug issues. For compatibility reasons, I will not change the current error messages since this could break CI in the wild. In addition, I don't expect users to extract the function name from the error message (if they want to, they should use this new attribute).
I considered also adding which Python function was the bad one, but since the exception is raised from a Python function, I think it's better not to do include an other attribute. If needed, we can always add it later but for now the curses C function name is more important.
Has this already been discussed elsewhere?
This is a minor feature, which does not need previous discussion elsewhere
Links to previous discussion of this feature:
No response
Linked PRs
Activityencukou commented on Oct 23, 2024 That's a lot of code to carry. Do you have a use case where the you'd want to get the C function programmatically while debugging? picnixz commented on Oct 23, 2024 For me no. But I felt that having the precise function that cause the exception would be worthwhile, without having to change the actual messages that were printed. I took inspiration from OSError and its filename/filename2 attributes.
I think it could be useful in a debugger or to render a custom error message. Note that having the exact function is important since having the w or mw prefix may change the assumptions the caller may have.
But it's really a minor feature which I found nice to have. If you think the diff is too large (and it is large because of all the small changes), we can drop it. Note that I included a minor cosmetic change where I shortened the name of some functions just for future maintenance but this commit can be dropped. encukou commented on Oct 23, 2024 But, is there a debugger that would want to add special handling specifically for curses.error?
If not, I recommend to drop this. picnixz commented on Oct 23, 2024 Not to my knowledge. I still think it's important to know which C function was the one that returned ERR (because the name of the function in the message is not always correct IMO) but if you prefer me to update the messages instead rather than adding an attribute, I can do it. If you think we should lie (a bit) to the user then we can keep the status quo. encukou commented on Oct 23, 2024 Yes, if it's a genuine improvement, make it for everyone; change the str.
cc @Yhg1s as the curses expert picnixz commented on Apr 25, 2025 I'm back on the PR and I eventually just changed all error messages instead of adding a new class & co. changed the title [-]Expose the name of the `curses` C function that caused the exception as an attribute of `curses.error`.[/-] [+]Improve error messages of `curses` by including failed C function[/+] on Apr 26, 2025changed the title [-]Improve error messages of `curses` by including failed C function[/-] [+]Improve error messages of `curses` by indicating failed C function[/+] on Apr 26, 2025picnixz commented on May 19, 2025 The rest will be addressed in #133579
MetadataMetadataStatusShow more project fields
DevelopmentNo branches or pull requestsIssue actions
|