Issue1717775

classification
Title: frame.f_trace ignored
Type: Severity: normal
Components: Core Versions:
Milestone:
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: cgroves, fabioz, zyasoft
Priority: normal Keywords:

Created on 2007-05-12.13:11:15 by fabioz, last changed 2008-09-14.06:36:30 by zyasoft.

Files
File name Uploaded Description Edit Remove
spaceship.py cgroves, 2007-05-20.20:39:37 Fabio's example
Messages
msg1596 (view) Author: Fabio Zadrozny (fabioz) Date: 2007-05-12.13:11:15
The tracing facility in python is used for profiling and debugging programs.
	
Profilers will usually trace all lines, so, setting sys.settrace and continually returning the trace_dispatch function is ok, but debuggers need to use frame.f_trace, to reenable tracing on parent frames after entering a new context that will have the debugger enabled, to handle step_return or normal steps (the debugger may actually work around that, but without that feature, there is no way of making any optimization to the debugger, as all function calls will have to be traced, which in the debugger case can make it almost useless).

Below is a sample program and the outputs in jython 2.1/2.2 and python2.2/2.4:

 1class spaceship:
 2            
 3    def m1(self):
 4        if 1:
 5            pass
 6        self.m2()
 7        
 8    def m2(self):
 9        if 1:
10            pass
11        self.m3()
12        
13    def m3(self):
14        if 1:
15            pass
16    
17if __name__ == '__main__':
18    
19    def trace_dispatch(frame, event, arg):
20        print frame.f_code.co_name, frame.f_lineno, event, arg
21        frame.f_trace = trace_dispatch
22        return None
23    
24    import sys
25    sys.settrace(trace_dispatch) 
26
27    tc = spaceship()
28    tc.m1()
29    tc.m2()
30    tc.m3()



jython output (2.1 and 2.2b):
m1 0 call None
m2 0 call None
m3 0 call None
m2 0 call None
m3 0 call None
m3 0 call None

python output (2.4):
m1 3 call None
m1 5 line None
m1 6 line None
m2 8 call None
m2 10 line None
m2 11 line None
m3 13 call None
m3 15 line None
m3 15 return None
m2 11 return None
m1 6 return None
m2 8 call None
m2 10 line None
m2 11 line None
m3 13 call None
m3 15 line None
m3 15 return None
m2 11 return None
m3 13 call None
m3 15 line None
m3 15 return None


python output (2.2):
m1 3 call None
m1 3 line None
m1 4 line None
m1 5 line None
m1 6 line None
m2 8 call None
m2 8 line None
m2 9 line None
m2 10 line None
m2 11 line None
m3 13 call None
m3 13 line None
m3 14 line None
m3 15 line None
m3 15 return None
m2 11 return None
m1 6 return None
m2 8 call None
m2 8 line None
m2 9 line None
m2 10 line None
m2 11 line None
m3 13 call None
m3 13 line None
m3 14 line None
m3 15 line None
m3 15 return None
m2 11 return None
m3 13 call None
m3 13 line None
m3 14 line None
m3 15 line None
m3 15 return None
msg1597 (view) Author: Charlie Groves (cgroves) Date: 2007-05-20.20:39:37
I've just attached a file version of your program.  If you wouldn't mind attaching files rather than including them in the future, that would make life much easier.  Sourceforge does a pretty abysmal job with the formatting.
File Added: spaceship.py
msg1598 (view) Author: Fabio Zadrozny (fabioz) Date: 2007-06-10.14:36:56
Actually, frame.f_trace is not completely ignored, just the behaviour changes from python...

If the frame.f_trace is set in another place (after the return from trace_dispatch), it seems to work... So, I think I can still work around it (the return seems to override frame.f_trace, whereas in python that doesn't happen).
msg3592 (view) Author: Jim Baker (zyasoft) Date: 2008-09-14.06:36:29
Apparently this slightly different behavior for CPython is acceptable
for debuggers, so closing for now.
History
Date User Action Args
2008-09-14 06:36:30zyasoftsetstatus: open -> closed
nosy: + zyasoft
resolution: wont fix
messages: + msg3592
2007-05-12 13:11:15fabiozcreate