[Python-Dev] bdb.py change from 1.31 to 1.31.2.1

[Mark Hammond]

> I have a problem with the current version of Pythonwin that I think I have
> tracked down to a change in bdb.py change 1.31 to 1.31.2.1, which dates
> 2002/05/29. Before you moan: "Pythonwin <> Python", please read on.

Well, Pythonwin <> Python <wink>.  The executive summary of the next 5
paras: Pythonwin simply worked around a few bdb bugs without bothering to
report them.  Python subsequently fixed some.  Pythonwin broke.  mea culpa.

Pythonwin worked around a number of "problems" with pdb.  A basic debugger
has existed for Pythonwin since before Python 1.5.2, and Pythonwin's
debugger itself has gone through a number of revisions.  pdb was really the
only reasonable debugger out there, so bdb has problems that pdb didn't
see - so noone saw them.

Pythonwin's debugger is complex, mainly due to the "recursive" nature of a
GUI debugger doing in-thread debugging of GUI code.  Python's debugger is
complex, simply as debugging is complex, and the variety of conditions under
which your hooks are called can be confusing.

Thus, I suffer from the perennial problem of it taking many hours for me to
get my head completely around the problem, and only minutes of distraction
to lose it again <wink>.  Thus, sorting out exactly who's fault each problem
was, and building demonstrable test cases for bdb shortcomings never really
got off the ground.

This is further compounded by the fact that I (obviously) rarely use the
Pythonwin debugger myself!  I rarely run programs inside Pythonwin at all
these days - the "in-process" nature coupled with my COM work etc means that
running inside Pythonwin means I need to shutdown Pythonwin to (eg) shutdown
Outlook/Word cleanly.  So I just alt-tab to a command-prompt, and run it
there.  I generally do my Pythonwin based debugging in the same way -
"pywin.debugger.brk()" in the source, and off I go in a new process.

I'd love to give Pythonwin out-of-process capabilities.  I'd love to do all
sorts of things <wink/frown>

> There was a thread about this recently on clp, and Mark Hammond proposed a
> fix (see <news:P4jw9.22603$jE1.72999@news-server.bigpond.net.au>) which
> takes on this bit - but doesn't change the "Go = break at first line of
> code" behaviour.

Oops :(  Note that the fix was to remove one of the work-arounds I mentioned
above.  I found it necessary to add an "artificial" call frame when starting
debugging, and now it appears I dont.  The "Go" fix will be similar when I
look for it - removing some pythonwin specific hack!

> * BUT IS IT REALLY A PROBLEM *
>
> I think so, because

Yep, it is - but not for the people on this list!  Pythonwin and win32
specific stuff isn't discussed on this list.
http://mail.python.org/mailman/listinfo/python-win32 is a list where it
would be on-topic.

> After lots of debugging I narrowed the problem down to bdb.py, and further
> to dispatch_call(). It seems that in the old version, the code read

As I mentioned, this is complex.  I can't answer your questions without
getting my head completely around the problem again (see above!)

As a clue:

> I'm not quite clear just
> as to *why* it works, but it *does* work.

While I can relate to the feeling, it doesn't really help.  *Someone* is
going to have to analyze this enough to answer the "why".  Without such a
person, this will flounder.  It is on my list of things to do <frown>

> 2) Is it a bug or a feature (i.e. a pythonwin bug rather than a
> bdb.py bug)

Certainly a bug in Pythonwin.

Mark.