[Python-3000] self-contained exceptions

[Phillip J. Eby]

At 08:10 AM 1/10/2007 +1100, Tim Delaney wrote:
>Guido van Rossum wrote:
>
> > On 1/8/07, Collin Winter <collinw at gmail.com> wrote:
> >> FWIW, I wasn't aware that things like "except T, (a, b, c):" were
> >> possible until I started work on this patch; I thought <name> was all
> >> you _could_ use.
> >
> > And, given the secial semantics for this position, I would support
> > changing the syntax to *only* allow a single simple name there -- not
> > even x.y.z. Thsh should handle 99.9% of existing code anyway.
> >
> > (And yes, if someone wants to add the 'as' keyword at the same time
> > that would be great!
>
>With such changed semantics (only allow simple name, simple name gets
>deleted at the end of the except: block) I would be strongly in favour of
>only having the changed semantics when the 'as' keyword is used.

That seems fine for 2.x, but 3.x should have Only One Way To Do It.  2.x 
needs both syntaxes to support writing forward-compatible code.


>Haven't checked the patch, but does it successfully delete the name in the
>case that another exception is thrown inside the except block?
>
>     try:
>         raise Exception()
>     except Exception as e:
>         try:
>             raise Exception()
>         except Exception as e2:
>             pass

Remmeber, the semantics are a source transform from:

    except <expr> as <name>:
        <suite>

to:

    except <expr>:
        <name> = <current exception value>
        try:
            <suite>
        finally:
            <name> = None
            del <name>

So just apply that expansion to all your examples to get your answers.  :)


>As I understand the proposed semantics, in the first case a NameError will
>be thrown at the 'print e' line in the first case, but not in the second
>case, because we never enter the second except: block. For consistency,
>maybe instead the semantics be that any name declared for catching an
>exception be deleted at the end of the try/except/else/finally clause i.e.
>
>     try:
>         pass
>     except AttributeError as e1:
>         pass
>     except NameError as e2:
>         pass
>
>is equivalent to:
>
>     try:
>         try:
>             pass
>         except AttributeError, e1:
>             pass
>         except NameError, e2:
>             pass
>     finally:
>         e1 = None
>         e2 = None
>         del e1
>         del e2

I find this explanation harder to explain.  The current model can be 
explained as:

"""The "as <name>" clause binds the exception value to <name>, then unbinds 
<name> when the <suite> is exited for any reason.  Any previous value bound 
to <name> is lost."""

I haven't thought of as simple a way to explain what you propose above.