[Python-Dev] Merging PEP 310 and PEP 340-redux?

Nick Coghlan ncoghlan at gmail.com
Wed May 11 22:55:48 CEST 2005


Paul Moore wrote:
> At the very least, there should be a section in "rejected
> alternatives" explaining why it is not appropriate to force reraising
> of exceptions unless explicit action is taken. There could be good
> reasons (as I say, I haven't followed the discussion) but they should
> be recorded. And if there aren't any good reasons, this behaviour
> should probably be changed.

This is a good point - it's one of the things I changed in the simplification of 
the semantics between 1.3 and 1.4 (previously the behaviour was much as you 
describe).

The gist is that the alternative is to require an __exit__() method to raise 
TerminateBlock in order to suppress an exception. Then the call to __exit__() in 
the except clause needs to be wrapped in a try/except TerminateBlock/else, with 
the else reraising the exception, and the except clause suppressing it. The 
try/except around BLOCK1 has to have a clause added to reraise TerminateBlock so 
that it isn't inadvertently suppressed when it is raised by user code (although 
that may be a feature, not a bug! - I'll have to think about that one)

Basically, it's possible to set it up that way, but it was a little ugly and 
hard to explain. "It's suppressed if you don't reraise it" is very simple, but 
makes it easier (too easy?) to inadvertently suppress exceptions.

If people are comfortable with a little extra ugliness in the semantic details 
of 'do' statements in order to make it easier to write correct __exit__() 
methods, then I'm happy to change it back (I think I just talked myself into 
doing that, actually).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com


More information about the Python-Dev mailing list