Paul Moore wrote:
> On 4/25/06, Nick Coghlan <[EMAIL PROTECTED]> 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 | [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
