Message 85494 - Python tracker (original) (raw)

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