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

[Paul Moore]

On 4/24/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
[...]
> The __iter__ method isn't called __iterator__, so why would the __context__
> method need to be called "__contextmgr__"?

Because......... Hmm, Oleg already responded to this, and to be
honest, I think the whole issue is a nitpick. Apologies for bringing
it up, it doesn't help.

> However, I'm definitely starting to agree with Just & Terry and whoever else
> said it that the basic object needs to be called something other than "context
> object". "context specifier" or something like that. (in fact, I might make a
> pass through the PEP & documentation to see how that looks. . .)
[...]
> >  (Oh, and by the way, writing this sentence
> > reinforced the reason I perfer the old terminology - "context manager"
> > feels like the name of something more concrete than "context", and yet
> > under your new terminology, the "context" is more concrete than the
> > "context manager"!)
>
> This is why I'm starting to think Terry and Just are right - the name of that
> type needs to be something other than "context object" in order to reduce the
> current ambiguity.

Right. I'll still do as I promised, and have a better look through the
latest documentation, but my gut feel is that this whole thing is
getting way out of proportion. Naming and terminology is important,
but we've now on our 3rd version of the docuentation.

My instinct is STILL that the original version of the docs were fine.

I can't express this in analytical terms, for which I apologise, but
I'm not sure it's an analytical issue. So if the following sounds
wooly, it's the best I can do :-)

The terms "context" (an abstract thingy relating to the environment in
which a block of code executes) and "context manager" (a concrete
object that manages contexts) seem natural to me. The fact that you
pass "context managers" to the "with" statement emphasizes the idea
that they are the concrete one of the pair.

Your version swaps the terms around, and so messes up my intuition. I
concede that your version is self-consistent, but it doesn't match my
intuition. And in my view, intuition matters here, so I have to prefer
the variant that matches my intuition.

Your point about the objects in the stdlib doesn't persuade me, I'm
afraid. All the threading examples have __context__ return self, so
they are, in some sense, both contexts and context managers (contexts
which are their own managers, if you like). Only decimal.Context is a
genuine context manager which creates independent context objects - I
concede that the name doesn't match my theory here, but I'm afraid *I
don't care*. I emphasize this, because it's an intuition thing again -
I know my terminology is (slightly) inconsistent with respect to the
decimal.Context class, but it doesn't disrupt my understanding. Worse
(in terms of explaining myself!) it still feels natural to stick with
decimal.Context even though I *know* that in my terms, it is formally
a context manager. (The best explanation I can give is that it sits
happily alongside the other places where I don't mind ignoring the
difference between "function returning X" and "X" when describing
things).

OK, I really can't explain that any better, but the library object
naming issue doesn't sway me.

Right, this is my final position:

I'm happy with the alpha-1 terminology. I would strongly prefer that
we go back to that.

I'd like to see the @contextmanager decorator split (conceptually, if
not actually) into 2 parts, one for use with generator functions which
are to be context managers, and one for use with __context__ functions
(generator functions which are to be functions returning contexts).
I'm willing to write up a patch doing the code changes for this, but I
don't hold out much hope of being able to write docs any better than
you or anyone else can!

I won't argue against any self-consistent terminology. But that's
because I'm not convinced of the value of having another round of
change/review on the docs - it doesn't mean I support it over the
alpha-1 version (and I'll probably still think in alpha-1 terms,
whatever ends up being agreed).

I think I've now read enough on the subject that my value as an
unbiased reader is being lost...

Paul.

PS Is anyone else arguing with Nick on this? Now that I'm reduced to
intuitive "well, I prefer it" arguments, it would be nice to hear what
people's gut feelings are - "contexts create context managers",
"context managers create contexts", "so confused I don't know"... :-)
?