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

[Nick Coghlan]

Paul Moore wrote:
> On 4/25/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
> I still found the alpha 1 terminology and documentation completely
> natural and intuitive. Completely. Not "acceptable", but "completely
> natural". From the perspective of someone with limited understanding
> of the design, looking to the documentation for enlightenment.

Don't get me wrong, I *like* the alpha1 terminology - looking at it in 
isolation it is very attractive (indeed, one of my early suggestions after AMK 
brought up the conflict between the docs and the implementation was to change 
the implementation to match the alpha 1 docs). But I backed away from that 
idea, because I believe the alpha 1 terminology will break badly as soon as 
you try to put it in a wider context. The term "context" is already overloaded 
with too many meanings (decimal arithmetic contexts, GUI drawing context 
objects, parser contexts, etc, etc).

Normally the overloaded meanings don't matter, because you'll be working in 
one problem domain or another, so it will be clear which meaning is intended. 
The issue this poses for the with statement, however, is that its just a 
programming tool, so its potential use spans all application domains. And 
under the alpha 1 terminology, almost none of those existing context objects 
would be able to serve as with statement context objects (at best, they'd be 
context managers).

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"

The only implementation changes needed then would be to change 
contextlib.contextmanager to contextlib.context, 
contextlib.GeneratorContextManager to contextlib.GeneratorContext and change 
decimal.ContextManager to decimal.WithStatementContext

> And that's got to be my last word. I can't judge the alpha 2
> documentation any more, I'm too close to the problem now. Heck, I no
> longer even have usable terms to describe the objects involved,
> because every reference has to be qualified with (a1 terminology) or
> (a2 terminology).

> So I'll bow out at this point. +1 on a1 terminology, can't judge on
> anything else. (Oh, and +100000 on just getting the damn thing
> resolved once and for all).

Since the only other two people who seem to really care about this are dead 
set against me, I'll see how the qualified term "with statement context 
object" pans out for clearing up any potential naming conflicts with 
domain-specific context objects, or with the nebulous entity that is the 
runtime context.

I haven't seen an alpha2 freeze announcement yet, so I hopefully still have 
time to look into this. . .

Cheers,
Nick.


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