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.)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4