-
-
Notifications
You must be signed in to change notification settings - Fork 31.9k
Idle: stop depending on console output #62518
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
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 #62281 also catches AttributeError as a bandage. [EDIT 2023 May 6: 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). |
This looks similar to #57791 with the patch to redirect console writes to a GUI text box. |
The proposal here is to flip the roles of text console and graphics gui, rather than to indefinitely bandage the current roles. I would want that even with the patch for #57791 applied (which I hope can be done soon). |
This point will be fixed by gh-101802. I agree with the rest, though. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: