[Python-checkins] python/dist/src/Python ceval.c,2.335,2.336

[mwh@users.sourceforge.net]

Update of /cvsroot/python/python/dist/src/Python
In directory usw-pr-cvs1:/tmp/cvs-serv29209/Python

Modified Files:
	ceval.c 
Log Message:
A slight change to SET_LINENO-less tracing.

This makes things a touch more like 2.2.  Read the comments in 
Python/ceval.c for more details.


Index: ceval.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Python/ceval.c,v
retrieving revision 2.335
retrieving revision 2.336
diff -C2 -d -r2.335 -r2.336
*** ceval.c	3 Sep 2002 20:19:06 -0000	2.335
--- ceval.c	11 Sep 2002 15:36:31 -0000	2.336
***************
*** 2910,2914 ****
  		      24 RETURN_VALUE
  
! 	   If a is false, execution will jump to instruction at offset
  	   15 and the co_lnotab will claim that execution has moved to
  	   line 3.  This is at best misleading.  In this case we could
--- 2910,2914 ----
  		      24 RETURN_VALUE
  
! 	   If 'a' is false, execution will jump to instruction at offset
  	   15 and the co_lnotab will claim that execution has moved to
  	   line 3.  This is at best misleading.  In this case we could
***************
*** 2921,2933 ****
  	   start of a line by the co_lnotab.
  
! 	   This also takes care of the situation where a is true.
  	   Execution will jump from instruction offset 12 to offset 21.
  	   Then the co_lnotab would imply that execution has moved to line
  	   5, which is again misleading.
  	*/
  
  	if ((frame->f_lasti < *instr_lb || frame->f_lasti >= *instr_ub)) {
  		PyCodeObject* co = frame->f_code;
! 		int size, addr;
  		unsigned char* p;
  
--- 2921,2943 ----
  	   start of a line by the co_lnotab.
  
! 	   This also takes care of the situation where 'a' is true.
  	   Execution will jump from instruction offset 12 to offset 21.
  	   Then the co_lnotab would imply that execution has moved to line
  	   5, which is again misleading.
+ 
+ 	   Why do we set f_lineno when tracing?  Well, consider the code
+ 	   above when 'a' is true.  If stepping through this with 'n' in
+ 	   pdb, you would stop at line 1 with a "call" type event, then
+ 	   line events on lines 2 and 3, then a "return" type event -- but
+ 	   you would be shown line 5 during this event.  This is a change
+ 	   from the behaviour in 2.2 and before, and I've found it
+ 	   confusing in practice.  By setting and using f_lineno when
+ 	   tracing, one can report a line number different from that
+ 	   suggested by f_lasti on this one occasion where it's desirable.
  	*/
  
  	if ((frame->f_lasti < *instr_lb || frame->f_lasti >= *instr_ub)) {
  		PyCodeObject* co = frame->f_code;
! 		int size, addr, line;
  		unsigned char* p;
  
***************
*** 2936,2939 ****
--- 2946,2950 ----
  
  		addr = 0;
+ 		line = co->co_firstlineno;
  
  		/* possible optimization: if f->f_lasti == instr_ub
***************
*** 2952,2961 ****
  				break;
  			addr += *p++;
! 			p++;
  			--size;
  		}
! 		if (addr == frame->f_lasti)
  			call_trace(func, obj, frame, 
  				   PyTrace_LINE, Py_None);
  		*instr_lb = addr;
  		if (size > 0) {
--- 2963,2974 ----
  				break;
  			addr += *p++;
! 			line += *p++;
  			--size;
  		}
! 		if (addr == frame->f_lasti) {
! 			frame->f_lineno = line;
  			call_trace(func, obj, frame, 
  				   PyTrace_LINE, Py_None);
+ 		}
  		*instr_lb = addr;
  		if (size > 0) {