[issue22764] object lifetime fragility in unittest tests

Change by Irit Katriel : -- stage: -> resolved status: pending -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue22764] object lifetime fragility in unittest tests

Irit Katriel added the comment: I don't think this test still exists - I tried to search for it and found nothing. In any case, from the discussion it seems that that is left is to tweak the skip mechanism (assuming the patches were applied). I'll close this soon if nobody objects.

[issue22764] object lifetime fragility in unittest tests

Antoine Pitrou added the comment: There's the cpython_only decorator in test.support. I think CPython is the only popular refcounting implementation. (of course I don't know which implementations may qualify as "popular" exactly :-)) -- ___ Python t

[issue22764] object lifetime fragility in unittest tests

Changes by Robert Collins : Added file: http://bugs.python.org/file37080/issue22764.patch ___ Python tracker ___ ___ Python-bugs-list mailing

[issue22764] object lifetime fragility in unittest tests

Robert Collins added the comment: I've done some experimentation. Yes, the updated test passes when the clear_frames call is removed in cPython 3.5 But the original test also passes when clear_frames is not called if one drops into pdb and steps through, which still fits the symptoms of having

[issue22764] object lifetime fragility in unittest tests

Antoine Pitrou added the comment: > Here's my understanding: the test is testing that a an object ref only held > in the traceback object of the exception is cleaned up such that it can be > collected The best way to check would be to revert the case.py changes in 6ab3193e890e. My intuition i

[issue22764] object lifetime fragility in unittest tests

Robert Collins added the comment: Hmm? I must have misunderstood the test. Here's my understanding: the test is testing that a an object ref only held in the traceback object of the exception is cleaned up such that it can be collected. In a refcount system that collection is immediate, in a g

[issue22764] object lifetime fragility in unittest tests

Antoine Pitrou added the comment: Le 30/10/2014 12:00, Robert Collins a écrit : > > Ah, perhaps the test was flawed to start with, since no effort is > made in it to capture the error and then process it. If we pass a result in, the traceback will have a ref and gc.collect() can't possibly be di

[issue22764] object lifetime fragility in unittest tests

Antoine Pitrou added the comment: You could instead mark the test as cpython-specific. -- ___ Python tracker ___ ___ Python-bugs-list

[issue22764] object lifetime fragility in unittest tests

Antoine Pitrou added the comment: I think the change in test_assertions is wrong: it doesn't test what the change was meant to fix in the first place. -- nosy: +pitrou ___ Python tracker __

[issue22764] object lifetime fragility in unittest tests

Changes by Robert Collins : -- type: -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.

[issue22764] object lifetime fragility in unittest tests

Robert Collins added the comment: Herewith a patch. Applied to unittest2 for backport to unbreak its tests on pypy. -- keywords: +patch Added file: http://bugs.python.org/file37072/issue22764.patch ___ Python tracker

[issue22764] object lifetime fragility in unittest tests

New submission from Robert Collins: test_assertRaises_frames_survival (unittest2.test.test_assertions.Test_Assertions Depends on refcount behaviour to pass - adding a gc.collect() before the weakref checks is sufficient to fix things on pypy. test_no_exception_leak (unittest2.test.test_case.Te