[Python-Dev] Acquire/release functionality (Was: Extended Function syntax)

[holger krekel]

Moore, Paul wrote:
> From: holger krekel [mailto:pyth@devel.trillke.net]
> 
> > Bernhard Herzog wrote:
> >
> > > Alex Martelli <aleax@aleax.it> writes:
> > >
> > > > > the exception should be propogated. The problem is that I'm not
> > > > > sure what is the best way for an __except__ method to signal
> > > > > that it caught the exception.
> > > >
> > > > Maybe the return value of __except__ should be evaluated in a
> > > > boolean context encoding this? False -> exception not caught, True
> > > > -> caught ...
> > >
> > > __except__ could just reraise the exception if it doesn't handle it.
> > > This behavior would be similar to that of a normal except clause   .
> >
> > exactly!
> 
> The problem in practice is that this means you have to take explicit action
> to say "I don't know what to do with this". I'd rather it was the other way
> round, with an empty exception handler
> 
>     def __except__(self): pass
> 
> doing nothing (as it looks). If you need to reraise, then this handler
> silently eats all exceptions. Basically, an empty handler should be the
> same as no handler. (If for no other reason than to give a subclass a
> way of disabling the superclass' handler).

With my approach i had all those hooks and __except__ in particular
*optional*.  So if you actually wrote 

    def __except__(self, type, value, traceback):
        ...

then i presume that you want to check something with the exception
(and that's why we should pass it in, btw.).  

It's difficult if you have an exception within __except__
because the interpreter would have to keep nested 'exception'
information.  So delegating the responsibility to __except__ is
the cleanest solution IMO.  All 'execution' hooks should only
handle events (enter/leave/except) but not push something back 
because it really complicates matters.
 
> Actually, it's clear to me that the controversial issues are:
> 
> 1. Multiple expressions in one with clause
> 2. Exception handling
> 
> Maybe the simplest answer is to remove both of these options, and stick
> with a slimmed down version which does gthe basics well. Does anyone have
> a good use case for either of these features?

Meanwhile i made a proposal in a new thread where i have some
use cases.  I am pretty sure that stating exception behaviour up-front
is not YAGNI.  At least for the xml-case there is a *very* nice use 
case (which i use in another project):

    XYZ html.tr():
        XYZ html.td():  compute_column()

now the html.td() handler can locally catch an exception 
and present an error-link which leads to a page containing
more information and a traceback.  Imagine you have to do this
with inline try-except clauses: you don't and then you get 
long meaningless tracebacks with hardly any context what went
wrong.  

With the aid of the __except__ hook you can still render 
the non-erranonous part of the page and give an immediate clue 
what went wrong and where.  So I think __except__ has the potential
to improve error-handling by abstracting it out into a method
instead of (redundantly) intermingling it with every thunk.

regards,

    holger