[Python-Dev] context guards, context entry values, context managers, context contexts

[Nick Coghlan]

Fredrik Lundh wrote:
> fwiw, I just tested
> 
>     http://pyref.infogami.com/with
> 
> on a live audience, and most people seemed to grok the "context
> guard" concept quite quickly.

Compared to the various other changes made lately to PEP 343, s/manager/guard/ 
would be a fairly straightforward one :)

I'm personally +1 on switching to 'guard' for the following reasons:
   - 'guarding' block entry and exit seems much more natural terminology to me 
than 'managing' entry and exit (since the block entry and exit is really still 
managed by the interpreter - the guard is just given the change to intervene 
in both cases).
   - 'manager' is a pretty generic term ('wooly' as Greg put it), so it needs 
to be qualified a lot more often than 'guard' does.
   - .NET uses 'managed code' in relation to sandboxes (as I understand it), 
so I suspect 'context manager' would up causing at least a bit of confusion in 
relation to IronPython

OTOH, I also think getting rid of __context__() has made the problems with the 
term context manager far less severe, so I'm not averse to the idea of leaving 
it alone, either.

> note sure about the "context entry value" term, though.  anyone
> has a better idea ?

The latest version of the PEP punts on this entirely - for most real use 
cases, you're going to be talking about a specific thing, anyway (such as the 
new decimal context returned by a decimal context manager).

"context entry value" really isn't that much better than "result of the 
__enter__ method", and the latter has the virtue of being explicit. . .

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org