Debugging on windows via print statements -- reliable?

[John Roth]

Since you're running a console app, I'd suggest two
changes to your test setup.

1) Execute the program from the DOS prompt, not from
PythonWin.
2) Redirect stdout to a file.

The first suggestion is simply to eliminate one possible
variable - if switching to a raw command prompt changes
something, you've got more data, if it doesn't, you've
eliminated a possible candidate.

At the command prompt, you can set up a .bat file
that runs the app very conveniently, and does the
redirection. It's a couple of keystrokes and mouse
taps more than running it under PythonWin, but I
find that it's worth it.

John Roth

"Nick Arnett" <narnett at mccmedia.com> wrote in message
news:mailman.1017034718.25848.python-list at python.org...
>
>
> > -----Original Message-----
> > From: python-list-admin at python.org
> > [mailto:python-list-admin at python.org]On Behalf Of Peter Hansen
>
>
> [snip]
>
> > By the way, how can Python code get "stuck"?  Is it a logic flaw,
> > or are you talking about the kind of "stuck" that used to happen,
> > in the "old days", when we were always writing code in languages
> > which would actually crash the computer?
>
> I'm using these vague adjectives because I can't tell what is
happening.
> Somewhere in the midst of retrieving pages with urllib and parsing
them with
> sgmllib, everything seems to stop.  And yes, it's a console app for
the
> moment.  I have a GUI that'll control it, but I'm working on pieces
that
> grab web pages, extract data and stick them in MySQL.  The only thing
I'm
> sure of is that it's not a problem with the database.  It happens at a
> different point each time, sometimes after a few dozen pages,
sometimes
> after a couple of hundred.  And I can re-do the same sequence of pages
and
> it'll freeze/loop/stop/whatever at a different point each time.  The
process
> is alive, there's no memory size change and it's consuming very few
CPU
> cycles when this happens.
>
> I'm working in PythonWin and I would have hoped that "break into
running
> code" would get me into it when this happens, so I could see where
it's
> getting stuck, but no, that would apparently be too convenient.
>
> Nick
>
>