[Zope3-dev] DISCUSS: Designing for debuggability

[Martijn Faassen]

Shane Hathaway wrote:
> Paul Everitt wrote:
[snip]
> >  o To wrap all this into end-to-end scenarios, what are five 
> >particularly egregious debugging situations to analyze, based on 
> >real-world experience over the last year?
> 
> I perceive a need for a pdb-like capability with a friendly UI and the 
> ability to debug higher level languages like DTML and page templates. 

I think this would help a lot. I'm one of those people who *can* 
start up a debugger and I know reasonably well to use one now, 
but I generally try to avoid reaching that point. 

If the debugger were built into Zope, preferably if at all possible in 
the ZMI (I know it's HTML based and clunky, but it's *always there*),
that would help me a lot. And I suspect many users are even less debugger
happy than I am. :)

Of course this might mean exposing Zope internals (source code) to the
ZMI more than we do now; we should at least have the option to make this,
say, only allowable from SSL connections or somesuch. Since one long term
plan is to make the difference between filesystem and ZODB based products
go away, I think this fits.

Being able to alter the debugger state while stepping through
code would be a security risk, and we may want to allow. But the ability
to step through code and put in breakpoints, as well as some basic
abilities to get the content of variables, should be possible, and 
already worth a lot. Especially if this could smoothly handle both
filesystem (Python) code as well as DTML, ZPT and Python scripts.
And in essence this isn't exposing that much more information than 
tracebacks already do. (oh, and being able to click on a line in a 
traceback and seeing the code in context would be neat too)

Regards,

Martijn