On 4/24/06, Nick Coghlan [EMAIL PROTECTED] wrote:
I'm going to try a pass through the docs using context specifier, which
gives three separate terms:
[...]
This removes the ambiguity between context object and runtime context.
That might just work. At the very least, I'd much rather see this
On Apr 24, 2006, at 03:49, Nick Coghlan wrote:
Just van Rossum wrote:
Baptiste Carvello wrote:
Terry Reedy a écrit :
So I propose that the context maker be called just that: 'context
maker'. That should pretty clearly not be the context that manages
the block execution.
+1 for context
Terry Reedy a écrit :
So I propose that the context maker be called just that: 'context maker'.
That should pretty clearly not be the context that manages the block
execution.
+1 for context maker. In fact, after reading the begining of the thread, I came
up with the very same idea.
Baptiste Carvello [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
+1 for context maker.
[me, Terry]
I would call the decorator @contextmaker since that is what it turns the
decorated function into.
I'm confused here. Do we agree that the object with __enter__ and
__exit__ is a
Just van Rossum [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
+1 for context maker.
Or maybe context factory?
Yes, I thought of that too. Latin 'facere' == 'to make'. I might even put
a sentence in the doc explaining that a context maker is a context factory,
in the CS sense of
Just van Rossum wrote:
Baptiste Carvello wrote:
Terry Reedy a écrit :
So I propose that the context maker be called just that: 'context
maker'. That should pretty clearly not be the context that manages
the block execution.
+1 for context maker. In fact, after reading the begining of the
Nick Coghlan [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
As Phillip pointed out, we need input from people that haven't been
intimately
involved in the PEP 343 discussions
OK, here is my attempt to cut the knot.
To me, 'context' and 'context manager' can be seen as near
