IDLE displays ANSI sequences in tracebacks when sys.excepthook is customized

[vstinner]

Error on Python 3.13 and newer.

Reproducer

• Run IDLE
• Set a custom sys.excepthook:

import sys
def hook(*args): return sys.__excepthook__(*args)
sys.excepthook=hook

• Trigger an error which display a traceback, such as accessing a variable which doesn't exist.

Output

>>> os
Traceback (most recent call last):
  File �[35m"/home/vstinner/python/3.13/Lib/idlelib/run.py"�[0m, line �[35m590�[0m, in �[35mruncode�[0m
    �[31mexec�[0m�[1;31m(code, self.locals)�[0m
    �[31m~~~~�[0m�[1;31m^^^^^^^^^^^^^^^^^^^�[0m
  File �[35m"<pyshell#12>"�[0m, line �[35m1�[0m, in �[35m<module>�[0m
�[1;35mNameError�[0m: �[35mname 'os' is not defined. Did you forget to import 'os'?�[0m

ANSI sequences to colorize the output are unexpected and makes the output hard to read.

Expected output

>>> os
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    os
NameError: name 'os' is not defined. Did you forget to import 'os'?

Explanation

In the normal case:

• IDLE replaces sys.stderr with io.StringIO() to call the "excepthook".
• _colorize.can_colorize() returns False.
• It works as expected.

If sys.excepthook is overridden:

• IDLE replaces sys.stderr with a idlelib.run.StdOutputFile object at startup.
• _colorize.can_colorize() returns True because StdOutputFile.isatty() always return True.

Linked PRs

• gh-127060: IDLE StdOutputFile is no longer a TTY #127061

[terryjreedy]

On Windows, 3.14.0a1 install or fresh build, I do not see this when running from editor.

Traceback (most recent call last):
  File "f:\dev\3x\Lib\idlelib\run.py", line 590, in runcode
    exec(code, self.locals)
    ~~~~^^^^^^^^^^^^^^^^^^^
  File "F:\dev\tem\tem.py", line 4, in <module>
    os
NameError: name 'os' is not defined. Did you forget to import 'os'?

After entering at prompt, the only differences are that the file is <pyshell#3> and os is missing. In CommandPrompt, the escape code highlighting (and the OS line) is present.

I do see the code on macOS, so I presume you are using mac or linux.

IDLE normally calls print_exception, which call a function to rid tracebacks of IDLE artifacts. When sys.excepthook is changed from sys.excepthook, the custom hook has to do this if desired. hook does not, hence the extra lines.

The absence of interactive code lines, such as os was part of the default sys.excepthook before 3.13. Python does not cache them. IDLE normally adds them and the new REPL does also.

I have thought about converting ~/^ to highlights. Since those lines might eventually go away when duplicated by inline markup, I have recently also thought of using the latter instead. It would be disappointing if that were not available on Windows.

IDLE always replaces the run process stderr with StdOutputfile. Normally, print_exception is called. After printing the traceback created by python while stderr is bound to an StdOutput file, it calls get_message_line to get SomeException: . For Attribute and Name errors, it temporarily replaces stderr to get the 'Did you mean' hints. (When hints are added for other exception classes, they should be added to the list.) This temporary replacement cannot affect the presence of color codes in the traceback itself.

The sys.stdxxx bindings are visible to user code. Changing an attribute might break the intended behavior of existing code.

[vstinner]

I do see the code on macOS, so I presume you are using mac or linux.

Right, I'm on Linux. I expected the behavior to be the same on Windows.

On Fedora, the ABRT service installs a custom sys.excepthook using a PTH file (.pth) to catch Python unhandled exceptions and report them to Bugzilla bug tracker.

So this IDLE bug is always reproduced on Fedora without having to install a custom excepthook manually, see: https://bugzilla.redhat.com/show_bug.cgi?id=2325502

[vstinner]

I expected the behavior to be the same on Windows.

Oh, I forgot that on Windows Python doesn't use ANSI sequences, but control directly the console using the Windows API. So right, Windows is not affected by this issue.