-
-
Notifications
You must be signed in to change notification settings - Fork 32k
gh-82005: Properly handle user input warnings in IDLE shell. #15311
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
base: main
Are you sure you want to change the base?
Conversation
Cease turning SyntaxWarnings into SyntaxErrors. Print warnings in the shell, not a possibly non-existent command line.
# Conflicts: # Lib/idlelib/pyshell.py
# Conflicts: # Lib/idlelib/pyshell.py
# Conflicts: # Lib/idlelib/pyshell.py
Thank you. I just fixed the merge conflict so I could get back to this. Will try to test soon. |
# self.write("Unsupported characters in input\n") | ||
# return | ||
# II.runsource() calls .runcode(), overridden below. | ||
with warnings.catch_warnings(): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great!
Just remember to remove the commented out code above before merging...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I created the PR on 2019 Aug 16, runsource comprised stuffsource(), a comment and assert, the inactivated code, and a try-finally block that wapped the override comment II.runsource() and and that fiddled with warnings in 'finally'.
The comment and assert were added and the code inactivated by MvL in 2007. The commit message was "Expect that source strings are unicode". Since str was bytes at the time, the message, comment, and assert do not make much sense to me. In any case, the comment and assert can be deleted. If IDLE were to pass bytes, there would be an error anyway.
I removed the inactivated code on Sept 16 in #16198 for bpo-38183 as an unrelated change. (A separate PR would have been better.) I only left it in the merge resolution because I was not sure then it should go (it should).
The try-finally was from KBK in 2001 and 2004. On Aug 26, in #15500 for this same issue (bpo-37824), I redid shell warnings and removed 'try' and the finally block, leaving the comment and II.runsource(). As for Cheryl's addition of a warnings filter, I will test and see if it should go in the warnings code to be executed just once and before running any user code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It appears that II.runsource is only use for code input after '>>>'. For instance, 'python -m idlelib -c "0 is "' only prints the warning once even without the filter. The patch otherwise moves it from the console to Shell. The current file level warnings manipulation does not save and restore filters. So I will leave the filter here until such time as code or codeop are patched (see issue) to make it unneeded in IDLE.
As for 'bug 2', warning printed before code (initial post): it does not look so bad now compared to alternatives. But the speculated reason is wrong. The same is true with multiple lines. But Bug 3: the warnings are printed with each return after the first, and there must be at least 2.
So scratch what I said before. 'Once' must apply across Enters, and, I think, at least across inputs between restarts, if not the whole session. |
This missed the boat for inclusion in Python 3.9 which accepts security fixes only as of today. |
Print warnings in the shell instead of the parent terminal, if there is one.
WIP Bug 1. Each warning printed 3 times. Will look in code.InteractiveInterpreter.
Bug 2. Warning inserted before code being warned about. My guess is that intercepted \n triggers compile which triggers warnings output before \n is passed to tk.Text to be inserted and move iomark. (I do not know when/where iomark is normally moved, but it seems not soon enough when compile warns). Shell.write changes gravity before and after calling OutputWindow.write, which I suspect moves the mark.