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 rbcollins
Recipients gregory.p.smith, michael.foord, pitrou, rbcollins
Date 2009-04-04.22:57:27
SpamBayes Score 3.690318e-09
Marked as misclassified No
Message-id <1238885834.2700.288.camel@lifeless-64>
In-reply-to <1238883040.6865.28.camel@fsol>
On Sat, 2009-04-04 at 22:09 +0000, Antoine Pitrou wrote:
> Antoine Pitrou <> added the comment:
> teardown
> Why should they? It's only an implementation choice, and not a wise one
> I would say (precisely because people are used to the fact that the
> standard tearDown() method does nothing, and doesn't need to be called).
> I explained my proposal in terms of actual use cases, but I don't see
> any actual use case of addCleanup() in your argument.

I was arguing by analogy: if we were to implement addCleanup as
something called at the end of the base class tearDown, then it would
clearly support LIFO tearing down of anything people have done [except
that we can't rely on them having called the base tearDown]. The next
best thing then is to call it from run() after calling tearDown.

If you want a worked example:
class TestSample(TestCase):

    def setUp(self):
        dirname = mkdtemp()
        self.addCleanup(shutils.rmtree, dirname, ignore_errors=True)
        db = make_db(dirname)


This depends on db being torn down before the rmtree, or else the db
teardown will blow up (and it must be torn down to release locks
correctly on windows).

Date User Action Args
2009-04-04 22:57:30rbcollinssetrecipients: + rbcollins, gregory.p.smith, pitrou, michael.foord
2009-04-04 22:57:29rbcollinslinkissue5679 messages
2009-04-04 22:57:27rbcollinscreate