At 04:01 PM 2/28/2006, Guido van Rossum wrote: >On 2/28/06, Nick Coghlan <[EMAIL PROTECTED]> 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.) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
