[Python-Dev] with-statement heads-up

Phillip J. Eby pje at telecommunity.com
Tue Feb 28 23:29:16 CET 2006

At 04:01 PM 2/28/2006, Guido van Rossum wrote:
>On 2/28/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > Guido van Rossum wrote:
> > > I just realized that there's a bug in the with-statement as currently
> > > checked in. __exit__ is supposed to re-raise the exception if there
> > > was one; if it returns normally, the finally clause is NOT to re-raise
> > > it. The fix is relatively simple (I believe) but requires updating
> > > lots of unit tests. It'll be a while.
> >
> > So does that mean with statements *will* be able to suppress 
> exceptions now?
> > (If I'm reading the PEP changes right it does, but I haven't finished my
> > coffee yet. . .)
>Yes. And unless there are peasants at the gate with pitchforks etc. it
>will stay that way. :-)

Notice that these semantics break some of the PEP examples.  For 
example, the 'locked' and 'nested' classes now suppress exceptions, 
and it took a non-trivial study of their code to determine 
this.  This seems to suggest that making suppression the default 
behavior is a bad idea.

I was originally on the side of allowing suppression, but I wanted it 
to be done by explicitly returning some non-None value, so that 
suppression would not be the default, implicit behavior.  I think I'd 
prefer not to be able to suppress the errors, than to have errors 
pass silently unless explicitly re-raised!  I don't see a problem 
with having e.g. __exit__ have to return a flag to suppress the 
exception; it wouldn't need to change how @contextmanager functions 
are written.  (Implicit suppression is only a problem for people 
writing __exit__ methods, in other words; all your reasoning about 
@contextmanager generators is valid, IMO.)

More information about the Python-Dev mailing list