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
IDLE: Fix AttributeError when running code #82183
Comments
Here's a new traceback I haven't seen before. I only see these at the end of a session, so I don't know which steps triggered it. $ python3.8 -m idlelib.idle tmp_pretty_fact_ast.py
Exception in Tkinter callback
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/tkinter/__init__.py", line 1883, in __call__
return self.func(*args)
File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/idlelib/runscript.py", line 173, in _run_module_event
interp.runcode(code)
File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/idlelib/pyshell.py", line 756, in runcode
self.interp.restart_subprocess()
AttributeError: 'ModifiedInterpreter' object has no attribute 'interp' |
You tried to run editor code and ran into a uncaught idle-process bug, which causes an exit. pyshell.ModifiedInterpreter.runcode: 760-1 The immediate bug is that 'self' *is* the interpreter with the restart_subprocess method, so '.interp' needs to be deleted. An easy fix in itself. Puzzle 1 is that I expect that 'executing' should be true whenever Shell is not waiting for a response to '>>>', so that we should be seeing this often. But it is false when running tkinter code, when sleeping, and when waiting for input(prompt) response, so I don't know how it was ever true for you. I don't remember ever seeing this exception. I will look at the code that sets and resets it. Maybe the former is not being called when it should be. Puzzle 2 is that the subprocess *is* being restarted even with this code being (normally) skipped. Is it ever needed, even in the (unknown) circumstance that 'executing' is true? Or would that cause two restarts? This would be a new buglet, though preferable to the current exception exit. The easy fix may not be enough. 'executing' and other shell booleans are still set as 0 and 1. I may update these first. |
Reproducer: In Shell, run "input('prompt'), Without giving a response, so that input is left 'executing', switch to editor with valid code, select "Run... Customized", unselect "Restart shell", and select OK. One will twice see and have to click away a box with Explanation: Run Module first compiles the editor code to check for syntax errors. If successful, it 1. restarts the execution process, which *resets executing to False*; 2. runs internal commands with runcommand (called twice) to change working directory, augment sys.path, and possibly change sys.args. 3. runs the compiled user code with runcode. Thus, the buggy 'executing' clause cannot be triggered. Run Customized with "Restart shell" unchecked skips the restart and 'executing' may be left True. If so, runcommand displays the message above and returns False, instead of running the command and returning True. The runscript code currently ignores the return and calls runcode anyway. Guiding principle: The effect of running with run customized with given settings should not depend on whether executable happens to be true when the first runcommand is called. I verified with time.sleep(15) that a statement can finish executing and executable reset to False while a user is reading the first 'executing' message. Since setting args has be skipped, the run should be stopped. Fixes:
|
Thank you for investigating this. |
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: