[Python-Dev] More on contextlib - adding back a contextmanager decorator

Mon May 1 04:10:46 CEST 2006

> At 09:53 AM 4/30/2006 -0700, Guido van Rossum wrote:
> >I have a counter-proposal: let's drop __context__.
[...]
> >   with mycontext.some_method(prec_incr=2):
> >       <BODY>

On 4/30/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> But what's an appropriate name for some_method?

Let's leave that up to the decimal lovers. You could call it push() or
stack() or establish() or some other non-descript word. Or manage() or
manager(). The method name can't involve the word "context" since the
object is already called a context. But that still leaves an infinite
number of possible names. :-)

> If you can solve the naming issue for these use cases (and I notice you
> punted on that issue by calling it "some_method"), then +1 on removing
> __context__.  Otherwise, I'm -0; we're just fixing one
> documentation/explanation problem (that only people writing contexts will
> care about) by creating others (that will affect the people *using*
> contexts too).

To the contrary. Even if we never come up with a perfect name for
decimal.Context.some_method(), then we've still solved a documentation
problem for 9 out of 10 cases where __context__ is just empty ballast.

But I'm sure that if we require that folks come up with a name, they will.

Things should be as simple as possible but no simpler. It's pretty
clear to me that dropping __context__ approaches this ideal. I'm sorry
I didn't push back harder when __context__ was first proposed -- in
retrospect, the first 5 months of PEP 343's life, before __context__
(or __with__, as it was originally called) was invented, were by far
its happiest times.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)