[Python-Dev] bdb.py change from 1.31 to 184.108.40.206
Mon, 11 Nov 2002 10:56:49 +1100
> 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 220.127.116.11, 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.email@example.com>) 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.