classification
Title: Test cases not garbage collected after run
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.4
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: michael.foord Nosy List: asvetlov, benjamin.peterson, charettes, ezio.melotti, fabioz, gvanrossum, haypo, matthewlmcclure, matthewlmcclure-gmail, meador.inge, michael.foord, pitrou, python-dev, r.david.murray, rhettinger, terry.reedy, tim.peters, tomwardill, tshepang, xdegaye
Priority: normal Keywords: patch

Created on 2011-04-07 16:15 by fabioz, last changed 2014-09-21 08:15 by berker.peksag. This issue is now closed.

Files
File name Uploaded Description Edit
11798.patch tomwardill, 2012-09-30 10:12 review
11798-20130803-matthewlmcclure.patch matthewlmcclure-gmail, 2013-08-04 17:25 review
issue11798.diff asvetlov, 2013-08-27 12:31 review
countTestCases.patch xdegaye, 2013-12-14 11:35 review
Messages (65)
msg133225 - (view) Author: Fabio Zadrozny (fabioz) Date: 2011-04-07 16:15
Right now, when doing a test case, one must clear all the variables created in the test class, and I believe this shouldn't be needed...

E.g.:

class Test(TestCase):
  def setUp(self):
    self.obj1 = MyObject()

  ...

  def tearDown(self):
    del self.obj1

Ideally (in my view), right after running the test, it should be garbage-collected and the explicit tearDown wouldn't be needed (as the test would garbage-collected, that reference would automatically die), because this is currently very error prone... (and probably a source of leaks for any sufficiently big test suite).

If that's accepted, I can provide a patch.
msg133226 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2011-04-07 16:21
You don't have to clear them; you just have to finalize them. Anyway, this is essentially impossible to do in a backward compatible way given that TestCases are expected to stay around.
msg133227 - (view) Author: Jean-Paul Calderone (exarkun) * (Python committer) Date: 2011-04-07 16:30
Trial lets test cases get garbaged collected.  When we noticed this wasn't happening, we treated it as a bug and fixed it.  No one ever complained about the change.  I don't see any obvious way in which an application would even be able to tell the difference (a user can tell the difference by looking at top).  In what case do you think this change would result in broken application code?
msg133228 - (view) Author: Fabio Zadrozny (fabioz) Date: 2011-04-07 16:34
I do get the idea of the backward incompatibility, although I think it's really minor in this case.

Just for some data, the pydev test runner has had a fix to clear those test cases for quite a while already and no one has complained about it (it actually makes each of the tests None after run, so, if someone tries to access it after that, it would be pretty clear that it's not there anymore).
msg133229 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2011-04-07 16:41
2011/4/7 Jean-Paul Calderone <report@bugs.python.org>:
>
> Jean-Paul Calderone <invalid@example.invalid> added the comment:
>
> Trial lets test cases get garbaged collected.  When we noticed this wasn't happening, we treated it as a bug and fixed it.  No one ever complained about the change.  I don't see any obvious way in which an application would even be able to tell the difference (a user can tell the difference by looking at top).  In what case do you think this change would result in broken application code?

I thought unittest was just handed a bunch of TestCase instances and
couldn't do much about insuring they were garbage collected.
msg133231 - (view) Author: Jean-Paul Calderone (exarkun) * (Python committer) Date: 2011-04-07 16:43
> I thought unittest was just handed a bunch of TestCase instances and couldn't do much about insuring they were garbage collected.

True.  But unittest could ensure that it doesn't keep a reference to each TestCase instance after it finishes running it.  Then, if no one else has a reference either, it can be garbage collected.
msg133232 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2011-04-07 16:50
A TestSuite (which is how tests are collected to run) holds all the tests and therefore keeps them all alive for the duration of the test run. (I presume this is the issue anyway.)

How would you solve this - by having calling a TestSuite (which is how a test run is executed) remove members from themselves after each test execution? (Any failure tracebacks etc stored by the TestResult would also have to not keep the test alive.)

My only concern would be backwards compatibility due to the change in behaviour.
msg133236 - (view) Author: Fabio Zadrozny (fabioz) Date: 2011-04-07 17:11
The current code I use in PyDev is below -- another option could be not adding the None to the list of tests, but removing it, but I find that a bit worse because in the current way if someone tries to access it after it's ran, it'll become clear it was removed.

def run(self, result):
    for index, test in enumerate(self._tests):
        if result.shouldStop:
            break
        test(result)

        # Let the memory be released! 
        self._tests[index] = None

    return result
    
    
I think the issue with the test result storing the test is much more difficult to deal with (because currently most unit test frameworks probably rely on having it there), so, that's probably not something I'd try to fix as it'd probably break many clients... in which case it should be expected that the test is kept alive if it fails -- but as the idea is that all has to turn green anyways, I don't see this as a big issue :)
msg133237 - (view) Author: Jean-Paul Calderone (exarkun) * (Python committer) Date: 2011-04-07 17:20
Here's Trial's implementation: http://twistedmatrix.com/trac/browser/trunk/twisted/trial/runner.py#L138
msg133239 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2011-04-07 17:27
Not keeping tests alive for the whole run seems like a good thing and either implementation seems fine to me. I'd be interested to hear if anyone else had any backwards compatibility concerns though.
msg133241 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2011-04-07 17:48
> Not keeping tests alive for the whole run seems like a
> good thing 

+1

> and either implementation seems fine to me.

I slightly prefer Fabio;s assignment to None approach (for subtle reasons that I can't articulate at the moment).
msg136961 - (view) Author: Fabio Zadrozny (fabioz) Date: 2011-05-26 13:47
So Michal, it seems no objections were raised?
msg136967 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2011-05-26 14:45
Sure, let's do it. Fabio, care to provide patch with tests and doc changes? (For 3.3.)
msg137464 - (view) Author: Fabio Zadrozny (fabioz) Date: 2011-06-01 23:14
Sure, will try to get a patch for next week...
msg171623 - (view) Author: Tom Wardill (tomwardill) * Date: 2012-09-30 10:12
Patch attached using setting test to None after execution.
msg171837 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2012-10-02 22:50
The patch looks good to me, although there probably needs to be a note in the TestSuite docs too. I'll apply this to Python 3.4, which leaves plenty of time for people to object.

Note that people needing the old behaviour can subclass TestSuite and provide a dummy implementation of _removeTestAtIndex.
msg188424 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2013-05-05 03:24
Just to be self-referential here's a link to #17908.
msg194228 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2013-08-03 01:56
If the iterator for 'self' were de-structive, if it removed (popped) the test from whatever structure holds it before yielding it, the messiness of enumerate and the new ._removeTestAtIndex method would not be needed and 'for test in self' would work as desired. If considered necessary,  new method .pop_iter, used in 'for test in self.pop_iter', would make it obvious that the iteration empties the collection.
msg194268 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-08-03 16:17
Terry: I would not be in favor of using the normal iter, since iterating a collection doesn't normally empty it, and there may be tools that iterate a test suite outside of test execution.  Adding a pop_iter method would be a backward compatibility issue, since "replacement" test suites would not have that method.  I think the current patch is the best bet for maintaining backward compatibility.
msg194398 - (view) Author: Matt McClure (matthewlmcclure-gmail) * Date: 2013-08-04 17:24
Michael Foord <fuzzyman <at> voidspace.org.uk> writes:
> On 2 Aug 2013, at 19:19, Antoine Pitrou <solipsis <at> pitrou.net> wrote:
> > The patch is basically ready for commit, except for a possible doc
> > addition, no?
> 
> Looks to be the case, reading the patch it looks fine. I'm currently on
> holiday until Monday. If anyone is motivated to do the docs too and 
> commit that would be great. Otherwise I'll get to it on my return.

It looks like the patch is based on what will become 3.4. Would backporting it to 2.7 be feasible?  What's involved in doing so?

I took a crack at the docs. I'm attaching an updated patch.
msg194430 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2013-08-04 21:27
This smells like a new feature to me (it's certainly a fairly significant change in behaviour) and isn't appropriate for backporting to 2.7.

It can however go into unittest2.

I agree with David that a destructive iteration using pop is more likely to cause backwards-compatibility issues.
msg194432 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2013-08-04 21:44
The doc patch looks good, thanks Matt. I'll read it through properly before committing.
msg196273 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2013-08-27 10:04
Looks good but review comments worth to be applied or rejected with reasonable note.
msg196275 - (view) Author: Matt McClure (matthewlmcclure-gmail) * Date: 2013-08-27 11:23
Andrew,

I didn't understand your message. Are you asking me to change the patch somehow? Or asking Michael to review and apply it?

Best,
Matt
msg196281 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2013-08-27 12:31
Matt, I've added new patch.

Will commit it after tomorrow if nobody object.
msg196282 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2013-08-27 12:32
Go ahead and commit. The functionality and patch are good.
msg196297 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2013-08-27 14:56
Matt, would you sign licence agreement http://www.python.org/psf/contrib/ ?
The Python Software Fondation is asking all contributors to sign it.
Thanks.
msg196300 - (view) Author: Matt McClure (matthewlmcclure) * Date: 2013-08-27 15:33
Andrew,

I signed the agreement as matthewlmcclure and as matthewlmcclure-gmail. Is there any way I can merge those two user accounts?

I believe the original patch was Tom Wardill's. I just updated his patch.
msg196301 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-08-27 15:43
There is no easy way to merge accounts in roundup.  If you've submitted the agreement, your "*" should show up in a bit :)
msg196402 - (view) Author: Roundup Robot (python-dev) Date: 2013-08-28 18:28
New changeset 1c2a37459c70 by Andrew Svetlov in branch 'default':
Issue #11798: TestSuite now drops references to own tests after execution.
http://hg.python.org/cpython/rev/1c2a37459c70
msg196404 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-08-28 19:27
This seems to be producing a test failure in test_doctest.  eg:

 http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%20dtrace%203.x/builds/1920
msg196406 - (view) Author: Matt McClure (matthewlmcclure) * Date: 2013-08-28 19:39
This might fix it (untested):

diff -r d748d7020192 Lib/test/test_doctest.py
--- a/Lib/test/test_doctest.py	Sat Aug 03 10:09:25 2013 -0400
+++ b/Lib/test/test_doctest.py	Wed Aug 28 15:35:58 2013 -0400
@@ -2329,6 +2329,8 @@
 
     Now, when we run the test:
 
+      >>> suite = doctest.DocFileSuite('test_doctest.txt',
+      ...                          optionflags=doctest.DONT_ACCEPT_BLANKLINE)
       >>> result = suite.run(unittest.TestResult())
       >>> print(result.failures[0][1]) # doctest: +ELLIPSIS
       Traceback ...
msg196431 - (view) Author: Roundup Robot (python-dev) Date: 2013-08-28 22:25
New changeset 17f23cf029cf by Andrew Svetlov in branch 'default':
Fix tests for #11798
http://hg.python.org/cpython/rev/17f23cf029cf
msg196433 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2013-08-28 22:52
Sorry. Tests are fixed now.
msg196607 - (view) Author: Meador Inge (meador.inge) * (Python committer) Date: 2013-08-31 01:55
I see some regressions when reference leak hunting with -j './python -j8 -R :'

test test_ast crashed -- Traceback (most recent call last):
  File "/home/meadori/src/cpython/Lib/test/regrtest.py", line 1265, in runtest_inne
r
    huntrleaks)  File "/home/meadori/src/cpython/Lib/test/regrtest.py", line 1381, in dash_R
    indirect_test()
  File "/home/meadori/src/cpython/Lib/test/regrtest.py", line 1261, in <lambda>    test_runner = lambda: support.run_unittest(tests)
  File "/home/meadori/src/cpython/Lib/test/support/__init__.py", line 1683, in run_
unittest
    _run_suite(suite)
  File "/home/meadori/src/cpython/Lib/test/support/__init__.py", line 1649, in _run
_suite
    result = runner.run(suite)
  File "/home/meadori/src/cpython/Lib/test/support/__init__.py", line 1548, in run
    test(result)
  File "/home/meadori/src/cpython/Lib/unittest/suite.py", line 76, in __call__
    return self.run(*args, **kwds)
  File "/home/meadori/src/cpython/Lib/unittest/suite.py", line 114, in run
    test(result)
  File "/home/meadori/src/cpython/Lib/unittest/suite.py", line 76, in __call__
    return self.run(*args, **kwds)
  File "/home/meadori/src/cpython/Lib/unittest/suite.py", line 114, in run
    test(result)
TypeError: 'NoneType' object is not callable
msg196618 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2013-08-31 07:17
Good catch!
That's because -R run the same test suite several times.
I'm working on patch.
msg196659 - (view) Author: Roundup Robot (python-dev) Date: 2013-08-31 17:55
New changeset 868ad6fa8e68 by Andrew Svetlov in branch 'default':
Temporary disable tests cleanup (issue 11798).
http://hg.python.org/cpython/rev/868ad6fa8e68
msg196665 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-08-31 18:51
Er... your latest commit broke this issue's own tests!
msg196701 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2013-09-01 04:41
All the buildbots are failing due to changeset 868ad6fa8e68 - I'm going to back it out.
msg196702 - (view) Author: Roundup Robot (python-dev) Date: 2013-09-01 04:45
New changeset 7035b5d8fc0f by Tim Peters in branch 'default':
Back out 868ad6fa8e68 - it left all the buildbots failing.
http://hg.python.org/cpython/rev/7035b5d8fc0f
msg196703 - (view) Author: Roundup Robot (python-dev) Date: 2013-09-01 04:58
New changeset 39781c3737f8 by Andrew Svetlov in branch 'default':
Issue #11798: fix tests for regrtest -R :
http://hg.python.org/cpython/rev/39781c3737f8
msg196705 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2013-09-01 05:13
Now 'regrtest.py -j4 -R : ' passes.
Do we need to add parameter for disabling tests cleanup to TestSuite, TestLoader and TestProgrm constructors?
msg196742 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2013-09-01 22:01
I'd rather not propagate more options all the way through, especially as this is some thing that should be decided by the test framework and is unlikely to be something you want to turn on and off per test run (which is what command line options are for). Frameworks that want to disable this behaviour should use a TestSuite that overrides _removeAtIndex.
msg196766 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2013-09-02 02:43
Ok. Let's close issue.
msg197712 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-09-14 14:31
> I'd rather not propagate more options all the way through, especially 
> as this is some thing that should be decided by the test framework and 
> is unlikely to be something you want to turn on and off per test run
> (which is what command line options are for). Frameworks that want to 
> disable this behaviour should use a TestSuite that overrides
> _removeAtIndex.

That sounds like a completely disproportionate solution. Why would you have to override the TestSuite class just to change an option and restore old behaviour? Why don't you simply expose the cleanup flag on TestSuite instances?
msg197713 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-09-14 14:32
For the record, this change broke the --forever option in Tulip's test script, which is why I'm caring. Setting the _cleanup flag to False seems to restore old behaviour, except that _cleanup is (obviously) a private API.
msg197714 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-09-14 14:36
Note: ideally, the --forever flag wouldn't reuse TestCase instances but rather create new ones.
msg197734 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2013-09-14 22:03
Can that be fixed in tulip?
msg197735 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-09-14 22:07
Yes, but that's not the point. Legitimate use cases can be broken by the change, so at least there should be an easy way to disable the new behaviour.
msg197888 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2013-09-16 10:30
If we're sure suite._cleanupis a *good* api for this then fine to expose it (and document) it as a public api. I'll take a look at it in a bit. 

Test suites will still have to do *some* monkeying around to set suite.cleanup (presumably in load_tests), so I'm not sure it's much more convenient...
msg198060 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-09-19 11:47
Ideally, test specification should be separate from test execution. That is, it should be possible to keep the TestCase around (or whatever instantiates it, e.g. a factory) but get rid of its per-test-execution attributes.

Perhaps restoring the original __dict__ contents would do the trick?
msg198062 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2013-09-19 11:58
That would only be a shallow copy, so I'm not sure it's worth the effort. The test has the opportunity in the setUp to ensure that initial state is correct - so I would leave that per test. Obviously sharing state between tests is prima facie bad, but any framework reusing test suites is doing that already.
msg198066 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-09-19 13:06
> That would only be a shallow copy, so I'm not sure it's worth the
> effort. The test has the opportunity in the setUp to ensure that
> initial state is correct - so I would leave that per test.

I don't understand your objection. The concern is to get rid of old
state after test execution.

> Obviously
> sharing state between tests is prima facie bad, but any framework
> reusing test suites is doing that already.

What do you mean?
msg198068 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2013-09-19 13:13
On 19 Sep 2013, at 14:06, Antoine Pitrou <report@bugs.python.org> wrote:

> 
> Antoine Pitrou added the comment:
> 
>> That would only be a shallow copy, so I'm not sure it's worth the
>> effort. The test has the opportunity in the setUp to ensure that
>> initial state is correct - so I would leave that per test.
> 
> I don't understand your objection. The concern is to get rid of old
> state after test execution.
> 

If the object state includes mutable objects then restoring the previous dictionary will just restore the same mutable (and likely mutated) object. To *properly* restore state you'd either need to deepcopy the dictionary or reinstantiate the testcase (not reuse it in other words). I'd rather leave it up to each test to ensure it reinitialises attributes in setUp than add further complexity that only does part of the job.

>> Obviously
>> sharing state between tests is prima facie bad, but any framework
>> reusing test suites is doing that already.
> 
> What do you mean?

Any framework that is currently reusing test suites is re-using testcase instances. They are already sharing state between the runs.

In fact messing with testcase dictionaries is a further possible cause of backwards incompatibility for those suites. 

> 
> ----------
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue11798>
> _______________________________________
msg198069 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-09-19 13:36
> If the object state includes mutable objects then restoring the
> previous dictionary will just restore the same mutable (and likely
> mutated) object.

I don't understand what you're talking about. Which mutable objects
exactly? I'm talking about copying the dict before setUp.

> >> Obviously
> >> sharing state between tests is prima facie bad, but any framework
> >> reusing test suites is doing that already.
> > 
> > What do you mean?
> 
> Any framework that is currently reusing test suites is re-using
> testcase instances. They are already sharing state between the runs.

They are not sharing it, since setUp will usually create the state
anew. What we're talking about is cleaning up the state after tearDown
is run, instead of waiting for the next setUp call.
msg198071 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2013-09-19 13:40
Ah right, my mistake. Before setUp there shouldn't be test state. (Although tests are free to do whatever they want in __init__ too and I've seen plenty of TestCase subclasses using __init__ when they should be using setUp.)

Essentially though _cleanup is a backwards compatibility feature - and suites that need _cleanup as a public api are already living without testcase dict cleanup.
msg198072 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-09-19 13:56
That said, I agree that the __dict__ proposal is a hack, but as is the current _removetestAtIndex mechanism.

The only clean solution I can think of would be to have two separate classes:
- a TestSpec which contains execution-independent data about a test case, and knows how to instantiate it
- a TestCase that is used for the actual test execution, but isn't saved in the test suite

Maybe it's possible to do this without any backwards compat problem by making TestSuite.__iter__ always return TestCases (but freshly-created ones, from the inner test specs). The main point of adaptation would be TestLoader.loadTestsFromTestCase().
msg198076 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2013-09-19 14:31
Having TestLoader.loadTestsFromTestCase() return a "lazy suite" that defers testcase instantiation until iteration is a nice idea.

Unfortunately the TestSuite.addTests api iterates over a suite to add new tests. i.e. the code that builds a TestSuite for module probably already iterates over the suites returned by TestLoader.loadTestsFromTestCase - so the change would need to be more pervasive.
msg198080 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-09-19 15:16
> Unfortunately the TestSuite.addTests api iterates over a suite to add
> new tests. i.e. the code that builds a TestSuite for module probably
> already iterates over the suites returned by
> TestLoader.loadTestsFromTestCase - so the change would need to be
> more pervasive.

addTests() could easily be tweaked to recognize that it gets passed a
TestSuite, and special-case that.

Also, TestCase objects could probably get an optional "spec" attribute
pointing to their TestSpec.
msg206177 - (view) Author: Xavier de Gaye (xdegaye) * Date: 2013-12-14 11:35
This seems to break BaseTestSuite.countTestCases when invoked after the TestSuite has been run:
  ...
  File "Lib/unittest/suite.py", line 42, in countTestCases
    cases += test.countTestCases()
AttributeError: 'NoneType' object has no attribute 'countTestCases'

Attached patch attempts to fix it.
msg207046 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-12-28 19:28
No answer to Xavier's regression? The way this issue is being treated is a bit worrying.
msg207047 - (view) Author: Roundup Robot (python-dev) Date: 2013-12-28 19:38
New changeset b668c409c10a by Antoine Pitrou in branch 'default':
Fix breakage in TestSuite.countTestCases() introduced by issue #11798.
http://hg.python.org/cpython/rev/b668c409c10a
msg207057 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2013-12-28 23:38
What's the purpose of _removed_tests in your fix, it doesn't appear to be used?
msg207070 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-12-29 11:14
It is used, see countTestCases().
msg207081 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2013-12-29 17:56
Ah yes, I see - sorry.
History
Date User Action Args
2014-09-21 08:15:26berker.peksagsetstatus: open -> closed
stage: resolved
2013-12-29 17:56:52michael.foordsetmessages: + msg207081
2013-12-29 11:14:46pitrousetmessages: + msg207070
2013-12-28 23:38:44michael.foordsetmessages: + msg207057
2013-12-28 19:38:05python-devsetmessages: + msg207047
2013-12-28 19:28:10pitrousetmessages: + msg207046
2013-12-14 11:35:52xdegayesetfiles: + countTestCases.patch
nosy: + xdegaye
messages: + msg206177

2013-10-06 20:07:28tshepangsetnosy: + tshepang
2013-10-06 15:42:18pitrousetnosy: + haypo
2013-09-19 15:16:05pitrousetmessages: + msg198080
2013-09-19 14:31:43michael.foordsetmessages: + msg198076
2013-09-19 13:56:04pitrousetmessages: + msg198072
2013-09-19 13:40:14michael.foordsetmessages: + msg198071
2013-09-19 13:36:54pitrousetmessages: + msg198069
2013-09-19 13:13:47michael.foordsetmessages: + msg198068
2013-09-19 13:06:50pitrousetmessages: + msg198066
2013-09-19 11:58:35michael.foordsetmessages: + msg198062
2013-09-19 11:47:47pitrousetmessages: + msg198060
2013-09-16 10:30:49michael.foordsetmessages: + msg197888
2013-09-14 22:07:04pitrousetmessages: + msg197735
2013-09-14 22:03:19michael.foordsetmessages: + msg197734
2013-09-14 14:36:55pitrousetmessages: + msg197714
2013-09-14 14:32:46pitrousetmessages: + msg197713
2013-09-14 14:31:54pitrousetstatus: closed -> open

messages: + msg197712
2013-09-02 02:43:44asvetlovsetstatus: open -> closed
resolution: fixed
messages: + msg196766
2013-09-01 22:01:49michael.foordsetmessages: + msg196742
2013-09-01 05:13:31asvetlovsetmessages: + msg196705
2013-09-01 04:58:56python-devsetmessages: + msg196703
2013-09-01 04:45:00python-devsetmessages: + msg196702
2013-09-01 04:41:53tim.peterssetnosy: + tim.peters
messages: + msg196701
2013-08-31 18:51:27pitrousetnosy: + pitrou
messages: + msg196665
2013-08-31 17:55:42python-devsetmessages: + msg196659
2013-08-31 07:17:12asvetlovsetstatus: closed -> open
resolution: fixed -> (no value)
messages: + msg196618
2013-08-31 01:55:58meador.ingesetnosy: + meador.inge
messages: + msg196607
2013-08-28 22:52:48asvetlovsetmessages: + msg196433
2013-08-28 22:25:05python-devsetmessages: + msg196431
2013-08-28 19:39:45matthewlmccluresetmessages: + msg196406
2013-08-28 19:27:51r.david.murraysetmessages: + msg196404
2013-08-28 18:29:31asvetlovsetstatus: open -> closed
resolution: fixed
2013-08-28 18:28:54python-devsetnosy: + python-dev
messages: + msg196402
2013-08-27 15:43:33r.david.murraysetmessages: + msg196301
2013-08-27 15:33:24matthewlmccluresetnosy: + matthewlmcclure
messages: + msg196300
2013-08-27 14:56:21asvetlovsetmessages: + msg196297
2013-08-27 12:32:50michael.foordsetmessages: + msg196282
2013-08-27 12:31:26asvetlovsetfiles: + issue11798.diff

messages: + msg196281
2013-08-27 11:23:08matthewlmcclure-gmailsetmessages: + msg196275
2013-08-27 10:04:58asvetlovsetnosy: + asvetlov
messages: + msg196273
2013-08-17 06:06:57charettessetnosy: + charettes
2013-08-04 21:44:37michael.foordsetmessages: + msg194432
2013-08-04 21:27:16michael.foordsetmessages: + msg194430
2013-08-04 17:25:57matthewlmcclure-gmailsetfiles: + 11798-20130803-matthewlmcclure.patch
2013-08-04 17:24:59matthewlmcclure-gmailsetnosy: + matthewlmcclure-gmail
messages: + msg194398
2013-08-03 16:17:33r.david.murraysetnosy: + r.david.murray
messages: + msg194268
2013-08-03 09:41:44exarkunsetnosy: - exarkun
2013-08-03 01:56:20terry.reedysetnosy: + terry.reedy
messages: + msg194228
2013-05-05 03:24:55gvanrossumsetnosy: + gvanrossum
messages: + msg188424
2012-10-02 22:50:11michael.foordsetmessages: + msg171837
2012-09-30 10:12:32tomwardillsetfiles: + 11798.patch

nosy: + tomwardill
messages: + msg171623

keywords: + patch
2012-09-28 11:33:16michael.foordsetversions: + Python 3.4, - Python 2.7, Python 3.2
2011-06-01 23:14:00fabiozsetmessages: + msg137464
2011-05-26 14:45:29michael.foordsetmessages: + msg136967
2011-05-26 13:47:14fabiozsetmessages: + msg136961
2011-04-07 18:33:49ezio.melottisetnosy: + ezio.melotti
2011-04-07 17:48:19rhettingersetnosy: + rhettinger
messages: + msg133241
2011-04-07 17:27:47michael.foordsetmessages: + msg133239
2011-04-07 17:20:45exarkunsetmessages: + msg133237
2011-04-07 17:11:42fabiozsetmessages: + msg133236
2011-04-07 16:50:50michael.foordsetassignee: michael.foord

messages: + msg133232
nosy: + michael.foord
2011-04-07 16:43:50exarkunsetmessages: + msg133231
2011-04-07 16:41:29benjamin.petersonsetmessages: + msg133229
2011-04-07 16:34:11fabiozsetmessages: + msg133228
2011-04-07 16:30:10exarkunsetnosy: + exarkun
messages: + msg133227
2011-04-07 16:21:51benjamin.petersonsetnosy: + benjamin.peterson
messages: + msg133226
2011-04-07 16:15:56fabiozcreate