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 ncoghlan
Recipients Julian, eric.snow, giampaolo.rodola, ncoghlan, nikratio, rhettinger, smarnach
Date 2011-12-13.03:02:35
SpamBayes Score 4.6629367e-15
Marked as misclassified No
Message-id <1323745357.76.0.797252464012.issue13585@psf.upfronthosting.co.za>
In-reply-to
Content
TestCase.setUp() and TestCase.tearDown() were amongst the precursors to__enter__() and __exit__(). addCleanUp() fills exactly the same role here - and I've seen *plenty* of positive feedback directed towards Michael for that addition to the unittest API.

For individual one-off cases, a flag variable and an if statement inside a finally block is an adequate, but not ideal, solution, because it suffers from all the readability and auditability problems of *any* try/finally based solution. It's particularly annoying when an object *does* support the context management protocol, but I can't use a with statement simply because I don't *always* need (and/or own) that resource (this kind of thing happens in a few places in runpy, since the behaviour changes depending on whether or not runpy created temporary objects for itself or was given objects as arguments)

Custom context managers are typically a bad idea in these circumstances, because they make readability *worse* (relying on people to understand what the context manager does). A standard library based solution, on the other hand, offers the best of both worlds:
- code becomes easier to write correctly and to audit for correctness (for all the reasons with statements were added in the first place)
- the idiom will eventually become familiar to all Python users

If other "cleanup function" registration APIs didn't already exist, I'd agree with you that this needed further exposure. However, I simply don't agree that's the case - atexit and addCleanup provide your field testing, the rest of the design is just a matter of integrating those concepts with the context management protocol.

Indeed, one of the objections I received after we deprecated contextlib.nested() was that you couldn't easily pass a programmatically generated list of resources to nested with statements. Given contextlib.CleanupManager it becomes trivial:

    with contextlib.CleanupManager as cm:
        files = [cm.enter_context(open(fname)) for fname in names]
        # All files will be closed when we leave the context

I can take this up on python-dev if you want, but I hope to persuade you that the desire *is* there, it's just that the workarounds for the lack of this functionality involve avoiding the context management protocol entirely:

    try:
        files = [open(fname) for fname in names]
        # Are all files closed when we're done?
        # I dunno, scroll down past the algorithm code to check!


        # Avoiding this would be good for all the reasons the
        # with statement was added in the first place

    finally:
        for f in files:
            f.close()
History
Date User Action Args
2011-12-13 03:02:38ncoghlansetrecipients: + ncoghlan, rhettinger, giampaolo.rodola, nikratio, Julian, eric.snow, smarnach
2011-12-13 03:02:37ncoghlansetmessageid: <1323745357.76.0.797252464012.issue13585@psf.upfronthosting.co.za>
2011-12-13 03:02:37ncoghlanlinkissue13585 messages
2011-12-13 03:02:36ncoghlancreate