[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