My debugger architecture, continued

I am on any shell operating any interpreter, the command:
debug(filename)

works.  That is sort of standard.  Two classes, pdb and dgui.

The python shell maps that into the appropriate dgui call,filling in missing arguments from parameter set up.

gui calls; pdb.init(filename)

Let's have dgui import the pdb function.  From then on,the  pdb focus,which is goes to dgui.  But pdb still operates the break call back,  

The seven basic list and grab commands, which are implemented in pdb, get moved to a generic pythn source search and list class operating on the source text.

If the default dgui is used, the system basically operates as it does now, except the shell gets the file management function.

In both cases, some 90% of the shell plus interpreter is used, exec() is still called everywhere.  No difference, really, its just that inserting a two dimensional window with placement intelligence results in a better debugger.

The python variables, they still have the appropriate life cycle, in the interpreter.  We just make sure, in the simplest method, the return from  dgui calls to  pdb to run and set breaks appropriately, it is still the break point manager. Simple, mostly done, really, and makes it easier to pre-select the gui functions of choice.  Some dgui as simply sophisticated data collectors and measurement tools, looking for that slow creeping bug.

Some dgui are used especially to debug Open Office macros.  They have the appropriate interfaces emulated for access to the cells, maybe even create a temporary,un-observable spreadsheet.  Then its run and debug away.