Guido van Rossum wrote:
I believe the context API design has gotten totally out of hand.
My thoughts exactly!
I have a counter-proposal: let's drop __context__... would it really be such a big deal to let the user make an explicit call to some appropriately named method?
Another possibility I thought of, for the case where an object is needed to keep track of the state of each invocation of a context, is to have the __enter__ method return the state object, which the with-statement tucks away and later passes to the __exit__ method. Also a thought on terminology. Even though it seems I may have been the person who thought it up originally, I'm not sure I like the term "manager". It seems rather wooly, and it's not clear whether a "context manager" is supposed to manage just one context or multiple contexts. I've been thinking about the terms "guarded context" and "context guard". We could say that the with-statement executes its body in a guarded context (an abstract notion, not a concrete object). To do this, it creates a context guard (a concrete object) with __enter__ and __exit__ methods that set up and tear down the guarded context. This seems clearer to me, since I can more readily visualise a "guard" object being specially commissioned to deal with one particular job (guarding a particular invocation of a context). With only one object, there wouldn't be a need for any more terms. But if another term is needed for an object with a __context__ method or equivalent, I rather liked Nick's "context specifier". -- Greg