This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author brett.cannon
Recipients Kristian.Vlaardingerbroek, brett.cannon
Date 2011-01-25.01:16:10
SpamBayes Score 3.406867e-07
Marked as misclassified No
Message-id <1295918170.87.0.013832209193.issue10990@psf.upfronthosting.co.za>
In-reply-to
Content
OK, now that all the modules have been analyzed, let's see what is what.

The modules not playing nicely with others by blindly reseting the trace module:

test_doctest
test_pdb
test_scope
test_sys_settrace
test_zipimport_support (because of test_doctest)

And the tests failing because of recursion depth:
test_exceptions
test_pickle
test_pickletools
test_richcmp
test_runpy

And test_io is just special thanks to signals and threading.

Here is my thinking on how to solve this. The tests that are not playing nicely with sys.settrace() should (a) be decorated with test.support.cpython_only, and (b) use addCleanup() to properly put the trace function back.

For the recursion depth tests, either the cause (which is probably trace_trampoline()) needs to be analyzed to decide if some other semantics are needed or need something to unset the trace function and then put it back, but only if sys.gettrace() exists (e.g., don't block on non-CPython VMs).
History
Date User Action Args
2011-01-25 01:16:10brett.cannonsetrecipients: + brett.cannon, Kristian.Vlaardingerbroek
2011-01-25 01:16:10brett.cannonsetmessageid: <1295918170.87.0.013832209193.issue10990@psf.upfronthosting.co.za>
2011-01-25 01:16:10brett.cannonlinkissue10990 messages
2011-01-25 01:16:10brett.cannoncreate