Phillip J. Eby wrote:
> 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."
I just checked in a change that reverts to the alpha 1 terminology, but uses
"with statement context" to work around the ambiguity issues. Hopefully as
just an interim fix until we find something better, but I could live with it
if I absolutely had to :)
'execution context object' I still find too ambiguous, because I'd like to be
able to drop the 'object' off the end and still have something that refers to
the right kind of object (just as we don't need to tack 'object' onto the end
of context manager all the time).
The best I've thought of is 'managed context' (and that only occurred to me
about five minutes ago):
"When requested by the with statement, a context manager returns a managed
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. :)
I'm definitely sold on that one - I included it as part of my latest checkin
since it dealt nicely with the alpha 1 documentation's contextmanager problem.
As you say, the fact that it's in contextlib provides ample indication that
it's talking about with statement contexts.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
