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

Nick Coghlan ncoghlan at gmail.com
Tue May 10 18:17:43 CEST 2005


Guido van Rossum wrote:
> [Nick]
> Is that use case strong enough to require the added complexity? For a
> transactional wrapper, I can see that __exit__ needs to know about
> exceptions (though I'm unsure how much detail it needs), but what's
> the point of being able to tell an exception from a non-local goto
> (which break, continue and return really are)?

The only real reason the statement template can tell the difference is because 
those non-local goto's all result in TerminateBlock being passed in as the 
exception (that's why the __exit__ method can't really tell the difference 
between those statements and the user code raising TerminateBlock, and also why 
TerminateBlock can't be suppressed by the statement template).

As far as use cases go, any case where we want the statement template to be able 
to manipulate the exception handling requires that this information be passed in 
to the __exit__() method. The current examples given in the PEP are 
transaction() and auto_retry(), but others have been suggested over the course 
of the discussion. One suggestion was for automatically logging exceptions, 
which requires access to the full state of the current exception.

I go into the motivation behind this a bit more in the updated draft I just 
posted (version 1.3). The basic idea is to allow factoring out of arbitrary 
try/except/else/finally code into a statement template, and use a 'do' statement 
to provide the contents of the 'try' clause.

If the exception information isn't passed in, then we can really only factor out 
try/finally statements, which is far less interesting.

> What's your use case for giving __enter__ an opportunity to skip the
> block altogether?

I realised that I don't have one - so the idea doesn't appear in the updated draft.

Regards,
Nick.

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


More information about the Python-Dev mailing list