python ides

Alex Martelli aleaxit at yahoo.com
Wed Sep 22 08:29:20 EDT 2004


Chris S. <chrisks at NOSPAM.udel.edu> wrote:
   ...
> >   http://wingware.com/downloads
> 
> Aside from being proprietary, how is WingIDE different from SPE 
> (spe.pycs.net)?

I'm not a big IDE user, but I've seen WingIDE's debugger in the hand of
an IDE-wizard, and it _is_ incredible.


>  > and finaly ,a super complete debuger , with support for plone/zope ,
>  > wxwindows and a lot of advanced options.
> 
> I'll give you this one, this I don't think SPE has a traditional 
> "debugger". Although to be fair, I've never needed one for Python.

I don't need one often, but sometimes one DOES run into something
sufficiently weird -- and when it happens it can take days to sort it
out.  Case in point: rewriting the web layer for a client's multi-tier
application framework, to use twisted and nevow instead of Webware, we
were occasionally getting the weirdest 'recursion limit exceeded'
tracebacks -- and if you've ever tried to divine what's going on from a
Twisted traceback with a few dozen deferreds in play, some intercepting
errors and some not, etc, etc, you know that isn't comfortable.

Two of us trashed around for 2-3 days trying all the usual things.
Finally one of the GUI specialists in another subteam of the same
framework development team offered to help us with WingIDE.  He's the
one who does custom layout widgets, weird super-nested-lists-and-
trees-widgets, etc etc, for the cross-platform GUI-clients of that
framework, on top of Qt/PyQt etc, and claims that without that debugger
he could never solve the weird and delicate issues that continually
arise in his work.

Be that as it may, in 2-3 hours we were on top of the problem: there is
an intrinsic, undocumented limit to how many items you can feed to a
newvow:sequence renderer, if those items are deferreds, because they all
get chained into a linked list whose __del__, at the end, proceeds _by
recursion_.  So, if you have too many items in the sequence, it's
recursion-limit-exceeded time, and the dance of bouncing exception
handlers starts playing (in a too-deep-nesting situation, too).  Once
the problem was identified the solution was trivial (as it generally
is): there was really no justification for showing a thousand 'hits' of
some search as one humungous table in a single webpage anyway... we
simply hadn't bothered yet with implementing the code to slice the hits
into multiple pages and let the user page back and forth in the browser.
So we did, ensuring no single sequence of hundreds of deferreds could
ever be rendered in one gulp, and the problem disappeared.

But, that debugger really DID save our bacon on that occasion.  I'm not
sure how it managed to get control at the right time within that thicket
of exception handlers and let us examine hundreds of nested stack frames
looking for the underlying cause (I know the cause sounds trivially
obvious in retrospect, but THAT, too, is par for the course... one of
the hardest bugs to find in my career, back in Fortran days, boiled down
in the end to an .LT. being used where an .LE. should have been... a
*one*-*character* fix after days of fighting to find the right place out
of over a million lines of code in the system...!-).  But manage it did.
Next time we spend more than 2-3 hours chasing some bug that just won't
show up, I'm going to go and ask that WingIDE expert user for some
little help!-)


Alex



More information about the Python-list mailing list