[Python-3000] self-contained exceptions

Wed Jan 10 18:32:57 CET 2007

"Greg Falcon" <veloso at verylowsodium.com> wrote:
[snip]
> I'm coming from a philosophy, though, that believes any time a
> syntactic construct creates a local binding and a new suite to use it
> in, the binding shouldn't escape that suite. Yes, I'm really talking
> about 'for', and I know this is probably a controversial view. But
> don't the same arguments apply? (It's probably an error to use the
> variable outside the suite, and if you really need to, you could be
> explicit and store another reference to it in a separate local.)

Yeah, I like reusing the variable names bound in a for loop. And unless
we are going to attempt to simplify the <assignment target> in...
 for <assignment target> in ...:
 ...
to only be a bare name, and not things like 'i, (j, k)', then removing
names is going to be difficult. I would be -1 on any changes to the for
loop syntax (value unpacking is so darn convenient), and without syntax
change, then variable bleeding semantics would be difficult to change 
(which I am also -1 on).
> re = get_resource()
> ...
> try:
> something()
> except RareException as re:
> ... # handle it
> ...
> re.use_resource()
>> Which *appears* to work fine most of the time, but when the
> RareException is raised and handled, suddenly the use_resource() line
> generates a surprising UnboundLocalError. These are the sort of
> things that should be caught ahead of time if possible.

According to the translation rules Colin has previously provided...
 re = get_resource()
 ...
 try:
 something()
 except RareException as re:
 ...
 ...
 re.use_resource()
is translated into...
 re = get_resource()
 ...
 try:
 try:
 something()
 except RareException:
 re = <current exception>
 ...
 finally:
 re = None
 del re
 ...
 re.use_resource()
That is, the 're = None; del re' stuff is executed regardless of whether
the except body is executed. The user would be notified right away.
 - Josiah