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, ngie, pitrou, rbcollins
Date 2009-04-05.13:49:57
SpamBayes Score 1.1961727e-08
Marked as misclassified No
Message-id <1238939379.28697.4.camel@lifeless-64>
In-reply-to <1238926585.6499.5.camel@fsol>
Content
On Sun, 2009-04-05 at 10:15 +0000, Antoine Pitrou wrote:
> Antoine Pitrou <pitrou@free.fr> added the comment:
> 
> > Our experience in bzr (we use this heavily, and migrated to it
> > incrementally across our 17K fixture suite) is that we rarely need to
> > use cleanups on dependent resources, and when we need to it has been
> > very easy to migrate the dependent resource to use cleanups as well.
> 
> I'm baffled. If you say you don't care about the order, why are you
> arguing at all?

I didn't say I don't care; I do - I care that it is robust and hard to
misuse. Having addCleanup() when called from a tearDown lead to cleanups
not being called would be an easy route to misuse.

> [...]
> > sequence 2: cleanup before teardown prevents using cleanups in base
> > class setup methods
> 
> The point is that sequence 2 can already be emulated using careful
> "try...finally" in tearDown, while sequence 1 cannot. That is, sequence
> 1 *needs* the addCleanup, while for sequence 2 it is a mere additional
> convenience.

I don't understand; neither sequence works - they are showing how any
choice [that retains the current simple proposed mechanism] cannot
interact without some failure modes with tearDown. Whichever point we
choose to have cleanups execute can be entirely emulated using careful
try:finally: in tearDown methods, so surely this is not an argument for
either order.

-Rob
History
Date User Action Args
2009-04-05 13:49:59rbcollinssetrecipients: + rbcollins, gregory.p.smith, pitrou, ngie, michael.foord
2009-04-05 13:49:58rbcollinslinkissue5679 messages
2009-04-05 13:49:57rbcollinscreate