db3l at fitlinxx.com
Wed Sep 22 18:22:01 EDT 2004
aleaxit at yahoo.com (Alex Martelli) writes:
> > But of course that mechanism is just as useful even if you could start
> > your own application, since it lets you minimize the debugging
> > overhead until you actually reach the right point (which might be
> > after some unknown amount of runtime).
> That's possible, too, though a debugger who's _only_ gonna catch
> exceptions might not have all that much overhead until an exception does
It's not quite that good, but still somewhat flexible. By importing
the stub module in your application, you're enabling it for debugging
from that point onwards. If the Wing IDE is running at that point
it'll immediately connect and then run under control of the debugger.
It won't stop the application, just keep running at the point onwards.
If the IDE isn't available, then the application will listen for
subsequent attach requests from Wing at which point the debugging
control will begin.
But, like most Python debuggers, the actual debugging is handled by
the trace hooks, so once actually attached to the IDE, you will pay
some penalty (not sure how much), even if you only care about
exceptions. Then again, a side benefit is that once attached you can
forceably interrupt the application at any moment.
So depending on that load, there can be an advantage to importing the
stub as late as possible (or as close to the debug point as possible)
and then just leaving the IDE running to service the connection at
that point. The other advantage the controlled import gives you is
that with most current Python releases debugging multiple threads
doesn't work well (I think it was 2.4 that improved hooks for this),
so you can control which thread imports the stub and that becomes the
thread being debugged.
All in all, pretty impressive. Ironically though, while this was the
key differentiator (well, that plus the source analysis - it was the
best IDE when I was looking at parsing the wxPython package for code
completion) I saw to the package, our use of TDD in our recent coding
has really ended up rarely needing much in the way of a debugger yet,
but it's nice to know what to buy when I need it. (And 2.0 hits a
number of the visual issues I had, with a development team
predominently on Windows currently, so I'm enthusiastically following
the current beta).
More information about the Python-list