[issue45560] sys.last_* not set for SyntaxErrors with IDLE

Terry J. Reedy added the comment: If this is not fixed, perhaps it should be documented along with other IDLE differences in Running User code. -- ___ Python tracker ___

[issue45560] sys.last_* not set for SyntaxErrors with IDLE

Terry J. Reedy added the comment: #43476 is clearly an enhancement request. It proposes to stash info in the GUI process in a way that lets it be into from the other process by non-standard means. This is closer to a bugfix request in that successive lines have a different response in REPL

[issue45560] sys.last_* not set for SyntaxErrors with IDLE

Terry J. Reedy added the comment: The method to run just code in userspace, without involving the debugger or history list, is runcommand. It needs a code string. The hard part is the code needed to recreate the exception instance in the user space. It will be different for SyntaxError ve

[issue45560] sys.last_* not set for SyntaxErrors with IDLE

Andre Roberge added the comment: If this can be implemented, then I believe that https://bugs.python.org/issue43476 could be closed as well. -- ___ Python tracker ___ ___

[issue45560] sys.last_* not set for SyntaxErrors with IDLE

Terry J. Reedy added the comment: This is most likely an oversight. It affects both normal and -n mode. The three sys attributes can be written. Given the error instance e caught in the IDLE process, we need to execute, *in the user namespace*, sys.last_type, sys.last_value, sys.tracebac

[issue45560] sys.last_* not set for SyntaxErrors with IDLE

New submission from Andre Roberge : As stated in the documentation, sys.last_type, sys.last_value and sys.last_traceback ... are set when an exception is not handled and the interpreter prints an error message and a stack traceback. This is true whether the exception is a SyntaxError or some