At 07:24 PM 4/25/2006 +1000, Nick Coghlan wrote: >So things like decimal.Context get left trying to find a sane name for what >their __context__ method returns. decimal.Context.__context__() returns a . . >. context? What? Wasn't it already a context? Oh, so it actually returns a >"with statement context object". But that object still isn't really the >context from a user's point of view - the context of interest to a user is >the >effect that object has on the runtime state (i.e. setting the decimal context >for the current thread). > >That said, that might actually still be salvageable if the term 'context >object' is appropriately qualified. . . > >"when requested by the with statement, a context manager returns a with >statement context object that sets up and tears down the desired runtime >context" If qualification of "context" is the only problem, I propose: context manager -- thing with __context__ method execution context object -- thing with __enter__/__exit__/__context__ execution context -- the abstract thing set up and torn down by the ECO "When requested by the with statement, a context manager returns an execution context object that sets up and tears down the desired execution context for the block." And I still call for @contextfactory as a decorator that creates a factory function returning an execution context. I don't think that calling it an "executioncontextfactory" or "executionfactory" or anything like that adds anything useful; it is after all coming from a library for dealing with execution contexts, so it's sufficiently clear, um, in context. :)
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