gh-134170: Add colorization to unraisable exceptions #134183
Conversation
| @@ -1485,6 +1485,21 @@ write_unraisable_exc_file(PyThreadState *tstate, PyObject *exc_type, | |||
| } | |||
| } | |||
|
|
|||
| // Try printing the exception with color | |||
| PyObject *print_exception_fn = PyImport_ImportModuleAttrString("traceback", | |||
There was a problem hiding this comment.
This would print the exception with color on stderr but write_unraisable_exc_file accepts arbitrary file objects. So:
- Let's use a separate function to print the exception with color
- Only import if
fileis not None.
There was a problem hiding this comment.
I just modified _print_exception_bltin to take a file, I don't think we need a new function. Is that alright?
There was a problem hiding this comment.
Actually, the comment for this function is:
Do nothing if sys.stderr attribute doesn't exist or is set to None
So I don't really know which one is the correct implementation. There are cases when sys.__stderr__ may be None (as said in the docs). OTOH, the Python function doesn't check for the existence of sys.stderr itself. So I think the comment is a bit misleading. Can you check which contract is the expected one? Thanks.+
There was a problem hiding this comment.
Hm, what am I checking for? If sys.stderr doesn't work, we'll raise an exception and fall back to the C implementation.
There was a problem hiding this comment.
But if sys.stderr does not exist, the function says "Do nothing if sys.stderr attribute doesn't exist or is set to None" which in this case isn't right as we're not doing "nothing" (we're still calling something). I'm not against your implementation, I'm just trying to understand the comment actually
There was a problem hiding this comment.
Hmm, yeah, I think that comment is wrong. Should I change it?
There was a problem hiding this comment.
Yes (wrong comments are misleading!)
There was a problem hiding this comment.
Did that and added an assertion. The caller always validates sys.stdout.
Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
|
Sorry, forgot about this PR!
I think this makes sense for a follow-up, because it'll apply to the current implementation as well, right? Ideally, that test would get backported. In general, we shouldn't have to worry too much about breaking things here, because we're just adding execution of Python code to a path where you could already execute arbitrary Python code. |
Yes. |
It's pretty now:
I don't think it's worth it/possible to add a test for this.
sys.unraisablehook#134170📚 Documentation preview 📚: https://cpython-previews--134183.org.readthedocs.build/