> 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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4