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 | [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
