pythonwin woes

[Kurt B. Kaiser]

Mark Hammond <mhammond at skippinet.com.au> writes:

> IDLE runs all programs in a new, external Python process, so never
> sees this issue.  In lots of ways, I like the way Pythonwin does it -
> keeping that state around can be very useful - eg, after the program
> has terminated, you can still see the objects etc.

The IDLE in Python 2.3 does use an external process, which, as you
say, completely avoids the reload/import dance.  It also substantially
separates the user's code from the IDLE code.

However, I should make it clear that IDLE's Python shell (which also
serves as the output window) looks at the subprocess and continues to
reflect the state of the most recent run of the program.  That is
indeed useful for inspecting the entrails and testing, and was a key
requirement during IDLE's re-design.

Run/Run Module (F5) will create a fresh subprocess, connect the Shell
window to it, and restart the program from scratch.  There is an
autosave feature, so re-running a program following modification is
one keystroke.  This is now the preferred way to use IDLE, rather than
initiating a re-run from the Shell window with reload() etc, though
that is still possible.

The shell's state will persist until it's restarted or F5 is keyed.
That is indicated with a   ====== RESTART =====  in the Shell window,
followed by any output from the new run.

It is still possible to copy lines and blocks of code forward in the
shell, even if they belong to a previous run.  That capability is very
useful for testing during development.

-- 
KBK