svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r83140 | alexander.belopolsky | 2010-07-25 11:02:55 -0400 (Sun, 25 Jul 2010) | 5 lines
Issue #9315: Renamed test_trace to test_sys_settrace and
test_profilehooks to test_sys_setprofile so that test_trace can be
used for testing the trace module and for naming consistency.
........
r83141 | alexander.belopolsky | 2010-07-25 11:05:42 -0400 (Sun, 25 Jul 2010) | 1 line
Corrected comments on where settrace and setprofile are tested.
........
made it try to set the line number from the trace callback for a 'call' event.
This patch makes the error message a little more helpful in that case, and
makes it a little less likely that a future editor will make the same mistake
in test_trace.
The mapping between bytecode offsets and source lines (lnotab) did not contain
an entry for the beginning of the loop.
Now it does, and the lnotab can be a bit larger:
in particular, several statements on the same line generate several entries.
However, this does not bother the settrace function, which will trigger only
one 'line' event.
The lnotab seems to be exactly the same as with python2.4.
Correction for issue1265 (pdb bug with "with" statement).
When an unfinished generator-iterator is garbage collected, PyEval_EvalFrameEx
is called with a GeneratorExit exception set. This leads to funny results
if the sys.settrace function itself makes use of generators.
A visible effect is that the settrace function is reset to None.
Another is that the eventual "finally" block of the generator is not called.
It is necessary to save/restore the exception around the call to the trace
function.
This happens a lot with py3k: isinstance() of an ABCMeta instance runs
def __instancecheck__(cls, instance):
"""Override for isinstance(instance, cls)."""
return any(cls.__subclasscheck__(c)
for c in {instance.__class__, type(instance)})
which lets an opened generator expression each time it returns True.
Backport candidate, even if the case is less frequent in 2.5.
on each iteration. I'm not positive this is the best way to handle
this. I'm also not sure that there aren't other cases where
the lnotab is generated incorrectly. It would be great if people
that use pdb or tracing could test heavily.
Also:
* Remove dead/duplicated code that wasn't used/necessary
because we already handled the docstring prior to entering the loop.
* add some debugging code into the compiler (#if 0'd out).
Re-enable all the tests in test_trace.py except one. Still not sure that these tests test what they used to test, but they pass. One failing test seems to be caused by undocumented line number table behavior in Python 2.4.
