Very elementary help in using Python on Windows 98

[Alex Martelli]

Jeff Melvaine wrote:

> I have begun to experiment with Python on Win98 on my personal laptop. 
> When I set up a script xxx.py and double click the icon to run it, I get a
> window (presumably some kind of debugging console)which lasts for a few
> seconds,
> flashes a message and dies instantly so I can't read it.  There is
> evidently a problem in my script somewhere, but how can I get the window
> to hang around long enough to see what it is?

Suppose your script is very well organized: only def and class statements 
first, including a def main statement creating a function named main, then 
at the end a statement such as:

if __name__=='__main__':
        main()

If so, then the only thing you need is to turn this last statement into:

if __name__=='__main__':
        try: main()
        finally: raw_input("Press Enter to terminate")

try/finally is a precious statement: the finally clause is executed no 
matter how the try clause terminates -- be it "normally", or because of an 
exception.  It's normally used to ensure some needed finalization.  In an 
environment which makes your console window disappear on termination, such 
as running a Windows program by double-clicking on an icon, you can look at 
this explicit "wait half a sec before closing the console" as a needed 
finalization.  On some Windows platforms you can set a console's properties 
to "no auto-closing" depending on the shortcut reached to open it, but I'm 
not sure this is available on Win98 nor how exactly to go about it -- it's 
not a Python question anyway, but a Windows one.

If your code is not as well organized as this, you can still use 
try/finally (all you have at top level now can be indented 4 spaces and go 
inside the try clause), although it would be worth taking the occasion to 
enhance program organization as well.


> When I start up the Python interpreter in its own window, it doesn't seem
> to
> know where my script is.  Do I need to set a path variable somewhere to
> tell

Not the way python.exe works today, alas: rather you have to give 
python.exe the complete path to your script (followed by arguments to the 
script, if any).  The SUBST command of COMMAND.COM, while old and rusty, 
sometimes comes in handy for that sort of stuff.

> I would probably find this much easier in Linux (given my experience on
> Unix stations at work, where writing much more complex scripts (even in
> Perl :) poses no real problems), but for an application running on this
> machine and reading data dumped from Excel and other Windows based
> applications, that is not an easy way for me to go.

You could consider Cygwin -- it's a good bash shell and a faithful 
imitation of as many aspects of Linux as Cygnus/RedHat could possibly fit 
into it -- you can also get an XFree86 port for Cygwin (comes with a lousy 
old window manager, twm, but once you have Cygwin and X read it's a snap to 
download tgz's, e.g. for WindowMaker, building it on Cygwin is no harder 
than ./configure, make, make install -- very much as it would be on Linux). 
Cygwin comes with a Python 2.1.1 port in the contrib directory, but I'm not 
sure if the latter does COM or can use win32all (I'd guess not) -- no 
problem, you can run Windows-native Python under Cygwin anyway, and still 
get the advantages of bash & good commandline tools.


Alex