This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author terry.reedy
Recipients ned.deily, roger.serwy, terry.reedy
Date 2013-06-27.22:43:29
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1372373009.47.0.618602359328.issue18318@psf.upfronthosting.co.za>
In-reply-to
Content
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!!!
    try:
        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).
History
Date User Action Args
2013-06-27 22:43:29terry.reedysetrecipients: + terry.reedy, ned.deily, roger.serwy
2013-06-27 22:43:29terry.reedysetmessageid: <1372373009.47.0.618602359328.issue18318@psf.upfronthosting.co.za>
2013-06-27 22:43:29terry.reedylinkissue18318 messages
2013-06-27 22:43:29terry.reedycreate