[New-bugs-announce] [issue18318] Idle: stop depending on console output

Terry J. Reedy report at bugs.python.org
Fri Jun 28 00:43:29 CEST 2013

New submission from Terry J. Reedy:

It appears that Idle was originally written to run on *nix after being launched from a command-line console. Messages related to Idle code (warnings and exceptions) are sent back to the console, while messages related to user code go to the shell window. This makes Idle a hybrid text/gui application.

Later, Idle was ported to run on Windows with the pythonw.exe no-console binary. When it is started normally for Windows, from anything but a console, there is no console. This has caused problems when Idle tries to write to the non-existent console. (I do not know the situation on modern Mac and *nix.) (Even when a console does exist, it will usually get buried and messages may not be seen.)

Example: The warning system, monkey patched in both PyShell.py and run.py and documented in the former. (Edited quote from 3.3.)

# Override warnings module to write to warning_stream.
# Initialize to send IDLE internal warnings to the console.
# ScriptBinding.check_syntax() will temporarily redirect the stream
# to the shell window to display warnings when checking user's code.
warning_stream = sys.__stderr__  # Typically None, at least on Windows.
def idle_showwarning(...
    if file is None:
        file = warning_stream  # Which may itself be None!!!
        file.write(...  # AttributeError when file is still None
    except OSError:
        pass  # if file (probably __stderr__) is invalid, skip warning.

The patch for #18081 also catches AttributeError as a bandage.

Issue goal: make Idle a true gui app by removing the dependence on a console, which may not exist.

Proposed method: re-factor Idle startup to try to import tkinter first, rather than last.

If this import fails, inform user with console message and/or the os-specific means to gui apps to tell users 'I cannot start because ...'. I know this exists on Windows because I have seen such messages. I presume same is true on other systems.

If this import succeeds, setup traceback and warnings hooks to send internal messages to a gui messagebox rather than (or possibly in addition to) a console that may or may not be present. Or send the messages to the Shell window, but marked somehow as internal. The warnings hook might be used after importing non-Idle modules but before importing Idle modules, so startup is not bogged down on debug builds by DeprecationWarnings from non-Idle modules

To be a good citizen for testing, all custom hooks should be undone before the PyShell import finishes and before PyShell.main exits (same for run.py).

messages: 191966
nosy: ned.deily, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: Idle: stop depending on console output
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

Python tracker <report at bugs.python.org>

More information about the New-bugs-announce mailing list