pythonwin woes

[oliver]

Hi,

I am trying my hands on the latest verion of pythonwin extension with
python 2.3.3 , and run into *semi-fatal* problem: the run command
ignores the modifications I made to the source code, and *always*
show me results given by that outdated source: it feels like it just
use that cached .pyc!!!

I wonder if the other pythonwin users had experienced the same
problem, or did I miss anything here. There is no such problem in IDLE
though.

Thanks

oliver

 

[Lucas Raab]

Hi,

I am trying my hands on the latest verion of pythonwin extension with
python 2.3.3 , and run into *semi-fatal* problem: the run command
ignores the modifications I made to the source code, and *always*
show me results given by that outdated source: it feels like it just
use that cached .pyc!!!

I wonder if the other pythonwin users had experienced the same
problem, or did I miss anything here. There is no such problem in IDLE
though.

Thanks

oliver

A while ago, I had the same exact problem. It always ran the outdated file.
I had to delete the old .pyc file to get it to run correctly. I'm running
Python 2.3.3 like you only I'm using build 157 and it seems to work just
fine. I had to go through a few versions before it went away with build 157.
Try emailing Mark Hammond and see if he had any suggestions.

 

[Mark Hammond]

Hi,

I am trying my hands on the latest verion of pythonwin extension with
python 2.3.3 , and run into *semi-fatal* problem: the run command
ignores the modifications I made to the source code, and *always*
show me results given by that outdated source: it feels like it just
use that cached .pyc!!!

I wonder if the other pythonwin users had experienced the same
problem, or did I miss anything here. There is no such problem in IDLE
though.

The difference will be that Pythonwin runs all programs "in process".
When you run a program for the second time, all of the 'import'
statements are still using the same module they imported before. The
solution is generally to *reload* the modules you change, before you run
the main script. Pressing Ctrl+I will do that for you - it will reload
the module if it was previously imported. After doing that, your main
script should see the new modules.

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.

Mark.

 

[oliver]

Thanks for your reply, Mark.

Yes, I can imagine scenarios where keeping the state around, the way
pythonwin is doing is useful. On the other hand, I think there is also
a need to restart python process to get a clean start. Maybe an
option for both is warranted.

oliver

 

[Kurt B. Kaiser]

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.

 

[Kylotan]

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.

IDLE keeps the state around after program termination too, so that you
can query it from the command line. It just gets rid of it when you
execute the next program (or re-execute the current one).