Regarding the interface between user code and the trap machine

Themmachine has trapped on some condition set up by the user.  How much code is needed to setup the user analysis within the trapped code under test?  Not much, the user supplied code can load all the modules it needs, hen run its own message loop.  Everything it needs is in a single class wihin the debugger, so just pass the instance and class.

as in:

import user
user.main(TestCode)

Or some equivalent code. The python  path manager does the rest.  The trap machine calls the init routine, in the default context, TestCode is a global class pointer.  Use it the same way the debugger does,then anything needed is there, via the class, including its own symbol table.

If we install the start up script, we avoid a file operation, we don;t move the head.  That means many, fast repeated calls to the user code, making the user free to write whatever check or stats without worry..  Leave it up to the user code to save the module, for faster import.  Or the user code can set up on the first call, then exchange the calling string for faster response later.  The user code incontrol of debugger operations.

The user code initializer is in the debugger init file, loaded, optionally, from the menu.  But all you need is:

TestCode.user_text = "\
\n what ever valid python atatements
\n you want to make
\n"

 Put that test right in yhe init.py file. You an load anything you want in TestCode,  It will have the init file, source file, call string, trap expression.  And once your code is called, change that around all you want. The best thing, really, is a compiled break expression, even if complex.  That will be placed first in the status loop. Remember the logic, traces exit immediately if trace is off.  After that, a run flag set appropriately can force immediate break testing.  Or, the run flag is set to normal step and break. I have this code in the filter, first check:

if(TestCode.flag == 3) : 
  exec(TestCode.breakexpression)  # this should set the flag for futher processing)
  if(TestCode.flag != 1) : return

So, have the user trap expression set the flag on return determining the further path of this trace call back.  And I will segment out the trace loop and have it compiled when things get solid.  The machine will be able to sit through days of looking without much burden once we understand how to interoperate the two traces.

So my focus in on implementing this call back and working the break filters.  Other odd bugs will get fixed as I spot them, but I need the ability to  write ad hoc analysis code behind  a solid trap machine.

Init code:

global WatchText
global TestCode
print("Initialization file")
TestCode.source_name = 'test.py'
inittest()
TestCode.breaks.append(l)

TestCode.breaks.append(5)
WatchText.insert('end',("%s      %s\n") % ("x","None") )
WatchText.insert('end',("%s      %s\n") % ("x+y","None" ))
TestCode.user_text = "print('User Break')"
print("done") 

We have a contradiction solved. Since the user is an experienced python developer, they can write set up scripts and the GUI does not become a nightmare. As it is, it is the best snippet viewer I have seen, execute, view, inspect; all in a small package.  So I can cut and past from the web, save snippets and play with therm with no hassle.