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