[Python-Dev] with-statement heads-up (original) (raw)

Guido van Rossum guido at python.org
Tue Feb 28 23:36:26 CET 2006

On 2/28/06, Phillip J. Eby <pje at telecommunity.com> wrote:

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 presume you're referring to example 4 (locked as a class), not example 1 (locked as a generator). I'll fix this, and rewrite nested() as a generator (just like what I checked in :-).

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.)

Thanks for the validation of the idea -- I ran into this when writing unittests for @contextmanager...

I think that providing sufficient correct examples will avoid most of the problems. People will clone existing examples (I know I did when adding context managers to various modules :-).

Changing the API to let exit() return something true to suppress the exception seems somewhat clumsy. Re-raising the exception is analogous to the throw() method in PEP 342.

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

More information about the Python-Dev mailing list