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