Improve error messages of `curses` by indicating failed C function

[picnixz]

Feature 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

• gh-125843: indicate which C function caused a curses.error #125844
• gh-125843: fix test_curses.test_attributes on x86-64 macOS #134252

[encukou]

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]

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]

But, is there a debugger that would want to add special handling specifically for curses.error?
If not, I recommend to drop this.

[picnixz]

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]

Yes, if it's a genuine improvement, make it for everyone; change the str.

cc @Yhg1s as the curses expert

[picnixz]

I'm back on the PR and I eventually just changed all error messages instead of adding a new class & co.