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

[Nick Coghlan]

Paul Moore wrote:
>> Aside from the What's New document, this has now been done. My modifications
>> consisted of terminology changes in the contextlib docs and the language
>> reference to match the 2.5a1 implementation, a Context Types addition to the
>> library reference similar to that for Iterator Types, and a very brief
>> addition to Chapter 8 of the tutorial. It should all filter through the
>> pipeline and appear on python.org in the next few hours.
> 
> OK, after a *very* quick look, here's my initial impression. I'll do a
> better look tomorrow.
> 
> - It seems self-consistent, now, at least.
> 
> - Surely the __context__ method should be called __contextmgr__ now
> that it's producing a context manager? (Same naming issue, just the
> other side of it...)

The __iter__ method isn't called __iterator__, so why would the __context__ 
method need to be called "__contextmgr__"?

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. . .)

> - I don't see why context managers (the ones with __enter__ and
> __exit__) need a __context__ method as well. To allow both contexts
> and context managers to be used with the "with" statement, it says.
> But there's no explanation of why that's a good thing. I see the
> parallel with "all iterators are iterables", but in the absence of the
> analog of the iter() builtin, I'm not so sure how I'd ever end up with
> a raw context manager (short of calling __context__ manually) to use
> in a with statement. So for my money, the iterator/context analogy
> breaks down here, precisely because raw iterators are far more common
> than raw context managers.

Context objects in the 2.5 standard library:
   decimal.Context

Context managers in the 2.5 standard library:
   file
   threading.Lock
   threading.RLock
   threading.Condition
   threading.Semaphore
   threading.BoundedSemaphore

Code that manipulates both context objects and context managers (like 
contextlib.nested, and the with statement itself) needs to be able to ignore 
the distinction. And yes, such code does indeed call __context__() directly in 
order to get hold of the context manager.

  (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.

Cheers,
Nick.

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