This is because the "Exception [was] ignored in atexit callback," meaning it only appears after you exit the repl, which therefore means it is not colored. I do not find this too surprising.

cc @ambv should this be closed?

Yes, in this case I don't think the REPL is able to re-add colorization. It's too late IMO.

We could totally add colorization here! Unraisable exceptions simply invoke sys.unraisablehook, which we can just modify to print the exception with color.

Here's a super rough POC:

import traceback
import sys
import atexit

def hook(unraisable):
    exc = unraisable.exc_value
    print(unraisable.err_msg, file=sys.stderr)
    traceback.print_exception(exc, colorize=True)

sys.unraisablehook = hook
def foo():
    raise Exception('foo')

atexit.register(foo)

Ideally, we'd just do this in C by calling into traceback._print_exception_bltin. The relevant line is here:

Shouldn't we chain the unraisable hooks then? what if someone already has a hook registered?

It wouldn't be any different than someone overwriting sys.excepthook.

Hum, maybe I misunderstood, but do you suggest we always colorize exceptions? wouldn't it be problematic to rely on colorization which is implemented in a Python file and could fail at exit? (namely, what happens if an error occurs during the colorization?)

We do always colorize exceptions in 3.13+, and fall back to the C implementation of traceback when it's not available. My proposal is to extend that behavior to sys.unraisablehook.

My proposal is to extend that behavior to sys.unraisablehook.

Is it safe to do it inside? namely is it safe to use this complex logic inside unraisablehook or not? if it's the case, I'm fine with this!

Yeah, it's completely safe. sys.unraisablehook can already call arbitrary Python code, so we're not really adding anything new in that sense.