[Python-Dev] PEP 343 update (with statement context terminology)

[Phillip J. Eby]

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.  :)