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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4