Alexander Belopolsky <belopol...@users.sourceforge.net> added the comment:
I am attaching another test file, y.py, which shows that the cause of
discrepancy is outside of the trace module. The traced function is the same as
in x.py only with 5 iterations instead of 10 for brevity, but instead of using
trace module, I am registering a custom trace function like this:
lines = []
def tracefunc(frame, what, arg):
if what == 'line':
lines.append(frame.f_lineno)
return tracefunc
sys.settrace(tracefunc)
3.1s: [3, 5, 3]
3.1g: [3, 5, 3, 4, 4, 4, 4, 4]
3.2s: [3, 5, 3, 3, 3, 3, 3, 3]
3.2g: [3, 5, 3, 4, 3, 4, 3, 4, 3, 4, 3, 4, 3]
Interestingly, this shows that effect of computed gotos is the same in 3.1 and
3.2 - adding a line event from "for i" line.
This situation illustrates the reason why I wanted to use synthetic events to
test the trace module rather than events generated by settrace machinery.
Apparently these differences have nothing to do with trace.py and everything
with ceval.c. If it is important to maintain stability of trace events between
python versions, tests (with appropriate sensitivity) should be added to
test_sys_setrace.
On the other hand, there are a lot of things that can go wrong in trace.py -
extracting code information from frame, divining the method and class names
etc. Ideally, this logic should be tested without reliance on details of event
generation.
----------
Added file: http://bugs.python.org/file18892/y.py
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue9315>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
