Debugging Code in the Python Shell
Code executed in Wing's Python Shell can be run with or without debug. This is controlled by clicking on the bug icon in the upper right of the tool, or using the Enable Debugging item in the Options menu. When debugging is enabled, a breakpoint margin appears at the left of the Python Shell tool, and breakpoints can be set here as in editors. This works for code previously typed, dragged, or pasted into the shell. Breakpoints set in editors will also be reached, if that code ends up being executed. Wing will copy breakpoints from a source file and stop in the Python Shell itself when Evaluate Selection is used on a short enough range of code. However, when using active ranges or evaluating a long selection or whole file Wing instead stops at breakpoints set within the code editor, since in those cases the code is not visible in the shell itself.
Note that the debugger only appears active when code is actually running, and not when waiting at the Python Shell prompt.
Whenever code is being debugged from a shell prompt, Stop Debugging and Start/Continue in the Debug menu, and their keyboard and toolbar equivalents, will return to the prompt in the shell. Both will continue executing code to complete the invocation from the prompt but Stop Debugging will do so with debug temporarily disabled. The fact that code is not preemptively interrupted is a limitation stemming from the way Python is implemented. In cases where this is a problem, the Python Shell can be restarted instead.
To interact recursively with code debugged from the Python Shell, use the Debug Probe or turn on Enabled Recursive Prompt in the Options menu. The latter presents a new prompt in the Python Shell whenever the debugger is paused or at a breakpoint, even if that shell is already in the process of executing code.
Debugging Threaded Code
Threads are treated differently in the Python Shell and Debug Probe depending on whether or not debug is enabled and/or whether the shell is at the prompt, as follows:
In the Python Shell, when debugging is disabled, threads are run continuously in the background without debug and whether or not the shell is at a prompt. When debugging is enabled in the Python Shell it will also debug threads. However, it will allow threads to run only while code is being executed from the shell and the Python Shell is not at the prompt. This matches the behavior of the debugger when it is running stand-alone files, where it halts all threads if any thread is halted. When the Python Shell is debugged, Wing treats execution of code from the shell prompt as continuing the debugger until the prompt is reached again. Thus it allows other threads to run as well.
In the Debug Probe, when debugging is disabled in its Options menu, threads are debugged but are halted whenever the main thread is halted in the debugger. Threads are not run even while executing code from the prompt in the Debug Probe so that data in all threads can be inspected without any unexpected change in runtime state caused by running of a thread. Threads will only continue running when the main debug program is continued. This is true whether or not the debug program was started from a file, or from within the Python Shell. As in the Python Shell, when debugging is enabled in the Debug Probe child threads will also be allowed to run whenever code is being executed recursively and the Debug Probe is not at the prompt. Threads are still halted whenever the Debug Probe is at the prompt
These subtle but necessary differences in threading behavior may affect how threaded code performs within the Python Shell and Debug Probe. Currently there are no options for selecting other behaviors (such as always letting threads run even when at the prompt, or never letting threads run even when executing code from the prompt). If you run into a situation where one of these options is needed, please send details of your use case to firstname.lastname@example.org.