Issue 11798: Test cases not garbage collected after run (original) (raw)
Created on 2011-04-07 16:15 by fabioz, last changed 2022-04-11 14:57 by admin. This issue is now closed.
Messages (68)
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.
Author: Benjamin Peterson (benjamin.peterson) * 
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.
Author: Jean-Paul Calderone (exarkun) *
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?
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).
Author: Benjamin Peterson (benjamin.peterson) *
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.
Author: Jean-Paul Calderone (exarkun) *
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.
Author: Michael Foord (michael.foord) *
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.
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 resultI 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 :)
Author: Jean-Paul Calderone (exarkun) *
Date: 2011-04-07 17:20
Here's Trial's implementation: http://twistedmatrix.com/trac/browser/trunk/twisted/trial/runner.py#L138
Author: Michael Foord (michael.foord) *
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.
Author: Raymond Hettinger (rhettinger) *
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).
Author: Fabio Zadrozny (fabioz) *
Date: 2011-05-26 13:47
So Michal, it seems no objections were raised?
Author: Michael Foord (michael.foord) *
Date: 2011-05-26 14:45
Sure, let's do it. Fabio, care to provide patch with tests and doc changes? (For 3.3.)
Author: Fabio Zadrozny (fabioz) *
Date: 2011-06-01 23:14
Sure, will try to get a patch for next week...
Author: Tom Wardill (tomwardill) *
Date: 2012-09-30 10:12
Patch attached using setting test to None after execution.
Author: Michael Foord (michael.foord) *
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.
Author: Guido van Rossum (gvanrossum) *
Date: 2013-05-05 03:24
Just to be self-referential here's a link to #17908.
Author: Terry J. Reedy (terry.reedy) *
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.
Author: R. David Murray (r.david.murray) *
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.
Author: Matt McClure (matthewlmcclure-gmail) *
Date: 2013-08-04 17:24
Michael Foord <fuzzyman voidspace.org.uk> writes:
On 2 Aug 2013, at 19:19, Antoine Pitrou <solipsis 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.
Author: Michael Foord (michael.foord) *
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.
Author: Michael Foord (michael.foord) *
Date: 2013-08-04 21:44
The doc patch looks good, thanks Matt. I'll read it through properly before committing.
Author: Andrew Svetlov (asvetlov) *
Date: 2013-08-27 10:04
Looks good but review comments worth to be applied or rejected with reasonable note.
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
Author: Andrew Svetlov (asvetlov) *
Date: 2013-08-27 12:31
Matt, I've added new patch.
Will commit it after tomorrow if nobody object.
Author: Michael Foord (michael.foord) *
Date: 2013-08-27 12:32
Go ahead and commit. The functionality and patch are good.
Author: Andrew Svetlov (asvetlov) *
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.
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.
Author: R. David Murray (r.david.murray) *
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 :)
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
Author: R. David Murray (r.david.murray) *
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
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 ...
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
Author: Andrew Svetlov (asvetlov) *
Date: 2013-08-28 22:52
Sorry. Tests are fixed now.
Author: Meador Inge (meador.inge) *
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 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
Author: Andrew Svetlov (asvetlov) *
Date: 2013-08-31 07:17
Good catch! That's because -R run the same test suite several times. I'm working on patch.
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
Author: Antoine Pitrou (pitrou) *
Date: 2013-08-31 18:51
Er... your latest commit broke this issue's own tests!
Author: Tim Peters (tim.peters) *
Date: 2013-09-01 04:41
All the buildbots are failing due to changeset 868ad6fa8e68 - I'm going to back it out.
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
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
Author: Andrew Svetlov (asvetlov) *
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?
Author: Michael Foord (michael.foord) *
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.
Author: Andrew Svetlov (asvetlov) *
Date: 2013-09-02 02:43
Ok. Let's close issue.
Author: Antoine Pitrou (pitrou) *
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?
Author: Antoine Pitrou (pitrou) *
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.
Author: Antoine Pitrou (pitrou) *
Date: 2013-09-14 14:36
Note: ideally, the --forever flag wouldn't reuse TestCase instances but rather create new ones.
Author: Michael Foord (michael.foord) *
Date: 2013-09-14 22:03
Can that be fixed in tulip?
Author: Antoine Pitrou (pitrou) *
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.
Author: Michael Foord (michael.foord) *
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...
Author: Antoine Pitrou (pitrou) *
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?
Author: Michael Foord (michael.foord) *
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.
Author: Antoine Pitrou (pitrou) *
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?
Author: Michael Foord (michael.foord) *
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>
Author: Antoine Pitrou (pitrou) *
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.
Author: Michael Foord (michael.foord) *
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.
Author: Antoine Pitrou (pitrou) *
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().
Author: Michael Foord (michael.foord) *
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.
Author: Antoine Pitrou (pitrou) *
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.
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.
Author: Antoine Pitrou (pitrou) *
Date: 2013-12-28 19:28
No answer to Xavier's regression? The way this issue is being treated is a bit worrying.
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
Author: Michael Foord (michael.foord) *
Date: 2013-12-28 23:38
What's the purpose of _removed_tests in your fix, it doesn't appear to be used?
Author: Antoine Pitrou (pitrou) *
Date: 2013-12-29 11:14
It is used, see countTestCases().
Author: Michael Foord (michael.foord) *
Date: 2013-12-29 17:56
Ah yes, I see - sorry.
Author: STINNER Victor (vstinner) *
Date: 2017-06-30 10:52
New changeset e4f9a2d2be42d5a2cdd624f8ed7cdf5028c5fbc3 by Victor Stinner in branch 'master': bpo-30813: Fix unittest when hunting refleaks (#2502) https://github.com/python/cpython/commit/e4f9a2d2be42d5a2cdd624f8ed7cdf5028c5fbc3
Author: STINNER Victor (vstinner) *
Date: 2017-06-30 11:12
New changeset 714afccf6e7644d21ce1a39e90bf83cb0c9a74f1 by Victor Stinner in branch '3.5': bpo-30813: Fix unittest when hunting refleaks (#2502) (#2506) https://github.com/python/cpython/commit/714afccf6e7644d21ce1a39e90bf83cb0c9a74f1
Author: STINNER Victor (vstinner) *
Date: 2017-06-30 11:12
New changeset 22d4e8fb99b16657eabfe7f9fee2d40a5ef882f6 by Victor Stinner in branch '3.6': bpo-30813: Fix unittest when hunting refleaks (#2502) (#2505) https://github.com/python/cpython/commit/22d4e8fb99b16657eabfe7f9fee2d40a5ef882f6
History
Date
User
Action
Args
2022-04-11 14:57:15
admin
set
github: 56007
2017-06-30 16:52:46
gvanrossum
set
nosy: - gvanrossum
2017-06-30 11:40:03
pitrou
set
nosy: - pitrou
2017-06-30 11:12:23
vstinner
set
messages: +
2017-06-30 11:12:18
vstinner
set
messages: +
2017-06-30 10:57:33
vstinner
set
pull_requests: + <pull%5Frequest2574>
2017-06-30 10:56:27
vstinner
set
pull_requests: + <pull%5Frequest2570>
2017-06-30 10:52:55
vstinner
set
messages: +
2017-06-30 10:38:05
vstinner
set
pull_requests: + <pull%5Frequest2563>
2014-09-21 08:15:26
berker.peksag
set
status: open -> closed
stage: resolved
2013-12-29 17:56:52
michael.foord
set
messages: +
2013-12-29 11:14:46
pitrou
set
messages: +
2013-12-28 23:38:44
michael.foord
set
messages: +
2013-12-28 19:38:05
python-dev
set
messages: +
2013-12-28 19:28:10
pitrou
set
messages: +
2013-12-14 11:35:52
xdegaye
set
files: + countTestCases.patch
nosy: + xdegaye
messages: +
2013-10-06 20:07:28
tshepang
set
nosy: + tshepang
2013-10-06 15:42:18
pitrou
set
nosy: + vstinner
2013-09-19 15:16:05
pitrou
set
messages: +
2013-09-19 14:31:43
michael.foord
set
messages: +
2013-09-19 13:56:04
pitrou
set
messages: +
2013-09-19 13:40:14
michael.foord
set
messages: +
2013-09-19 13:36:54
pitrou
set
messages: +
2013-09-19 13:13:47
michael.foord
set
messages: +
2013-09-19 13:06:50
pitrou
set
messages: +
2013-09-19 11:58:35
michael.foord
set
messages: +
2013-09-19 11:47:47
pitrou
set
messages: +
2013-09-16 10:30:49
michael.foord
set
messages: +
2013-09-14 22:07:04
pitrou
set
messages: +
2013-09-14 22:03:19
michael.foord
set
messages: +
2013-09-14 14:36:55
pitrou
set
messages: +
2013-09-14 14:32:46
pitrou
set
messages: +
2013-09-14 14:31:54
pitrou
set
status: closed -> open
messages: +
2013-09-02 02:43:44
asvetlov
set
status: open -> closed
resolution: fixed
messages: +
2013-09-01 22:01:49
michael.foord
set
messages: +
2013-09-01 05:13:31
asvetlov
set
messages: +
2013-09-01 04:58:56
python-dev
set
messages: +
2013-09-01 04:45:00
python-dev
set
messages: +
2013-09-01 04:41:53
tim.peters
set
nosy: + tim.peters
messages: +
2013-08-31 18:51:27
pitrou
set
nosy: + pitrou
messages: +
2013-08-31 17:55:42
python-dev
set
messages: +
2013-08-31 07:17:12
asvetlov
set
status: closed -> open
resolution: fixed -> (no value)
messages: +
2013-08-31 01:55:58
meador.inge
set
nosy: + meador.inge
messages: +
2013-08-28 22:52:48
asvetlov
set
messages: +
2013-08-28 22:25:05
python-dev
set
messages: +
2013-08-28 19:39:45
matthewlmcclure
set
messages: +
2013-08-28 19:27:51
r.david.murray
set
messages: +
2013-08-28 18:29:31
asvetlov
set
status: open -> closed
resolution: fixed
2013-08-28 18:28:54
python-dev
set
nosy: + python-dev
messages: +
2013-08-27 15:43:33
r.david.murray
set
messages: +
2013-08-27 15:33:24
matthewlmcclure
set
nosy: + matthewlmcclure
messages: +
2013-08-27 14:56:21
asvetlov
set
messages: +
2013-08-27 12:32:50
michael.foord
set
messages: +
2013-08-27 12:31:26
asvetlov
set
files: + issue11798.diff
messages: +
2013-08-27 11:23:08
matthewlmcclure-gmail
set
messages: +
2013-08-27 10:04:58
asvetlov
set
nosy: + asvetlov
messages: +
2013-08-17 06:06:57
charettes
set
nosy: + charettes
2013-08-04 21:44:37
michael.foord
set
messages: +
2013-08-04 21:27:16
michael.foord
set
messages: +
2013-08-04 17:25:57
matthewlmcclure-gmail
set
files: + 11798-20130803-matthewlmcclure.patch
2013-08-04 17:24:59
matthewlmcclure-gmail
set
nosy: + matthewlmcclure-gmail
messages: +
2013-08-03 16:17:33
r.david.murray
set
nosy: + r.david.murray
messages: +
2013-08-03 09:41:44
exarkun
set
nosy: - exarkun
2013-08-03 01:56:20
terry.reedy
set
nosy: + terry.reedy
messages: +
2013-05-05 03:24:55
gvanrossum
set
nosy: + gvanrossum
messages: +
2012-10-02 22:50:11
michael.foord
set
messages: +
2012-09-30 10:12:32
tomwardill
set
files: + 11798.patch
nosy: + tomwardill
messages: +
keywords: + patch
2012-09-28 11:33:16
michael.foord
set
versions: + Python 3.4, - Python 2.7, Python 3.2
2011-06-01 23:14:00
fabioz
set
messages: +
2011-05-26 14:45:29
michael.foord
set
messages: +
2011-05-26 13:47:14
fabioz
set
messages: +
2011-04-07 18:33:49
ezio.melotti
set
nosy: + ezio.melotti
2011-04-07 17:48:19
rhettinger
set
nosy: + rhettinger
messages: +
2011-04-07 17:27:47
michael.foord
set
messages: +
2011-04-07 17:20:45
exarkun
set
messages: +
2011-04-07 17:11:42
fabioz
set
messages: +
2011-04-07 16:50:50
michael.foord
set
assignee: michael.foord
messages: +
nosy: + michael.foord
2011-04-07 16:43:50
exarkun
set
messages: +
2011-04-07 16:41:29
benjamin.peterson
set
messages: +
2011-04-07 16:34:11
fabioz
set
messages: +
2011-04-07 16:30:10
exarkun
set
nosy: + exarkun
messages: +
2011-04-07 16:21:51
benjamin.peterson
set
nosy: + benjamin.peterson
messages: +
2011-04-07 16:15:56
fabioz
create