python ides

[Alex Martelli]

David Bolen <db3l at fitlinxx.com> wrote:

> aleaxit at yahoo.com (Alex Martelli) writes:
> 
> > > hits that point (whether it's running deep inside a web server, or any
> > 
> > ...we WERE "deep inside a web server" (one coded with Twisted)...
> 
> Ah, I sort of assumed (since you mentioned Twisted) that it was a
> server you could start up from scratch completely under Wing's control
> and then take it to the point of failure just letting Wing's normal
> exception catching mechanism work - thus, just starting it from the IDE.

Sigh, not quite, the startup isn't all plain sailing.


> The exception trapping support of Wing, BTW, as you also mentioned, is
> definitely impressive since it's the only one I've seen that can cross
> the Python->C Extension-Python boundary and still trap an exception.
> Works great with exceptions in wxPython applications since those all
> occur on the other "side" of the wxPython extension, and aren't
> generally caught by other debuggers i've tried.  Of course, this does
> occasionally catch "normal" exceptions suppressed by such extensions
> that you then need to ignore, but Wing makes that simple too.

I assume (without knowing in depth) that's part of what makes it so
indispensable to the guy who's coding deep and complicated stuff in
PyQt: there's plenty of C++ code there, just as in wx{Widgets,Python}.

 
> The environments I was originally envisioning were those where you
> really couldn't manually start the application directly from Wing.  So
> in the web case, something like Apache using mod_python, or perhaps
> when trying to debug a COM server that is initiated as an in-proc
> server from a C++ application.

Yeah, there's a lot of that going around -- Python embedded in other
apps or other cases where the Python part you're interested in must be
started under another app's control (you might simulate the startup some
of the time, but it can be bothersome or even nigh-impossible).


> 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
happen.


Alex