[Python-3000] self-contained exceptions

[Guido van Rossum]

On 1/11/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 03:42 PM 1/11/2007 -0600, Collin Winter wrote:
> >On 1/11/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> >>At 03:33 PM 1/11/2007 -0500, Terry Reedy wrote:
> >> >Yes, I already see it that way.  It would be nice if the rule for 'as'
> >> >targets were as consistent as possible (ie, at least the same for except
> >> >and with)
> >>
> >>No can do - with needs tuples, except isn't getting them.
> >>
> >>If we did allow tuples in both cases, the "except" ones wouldn't be cleared
> >>at the end of the block, but the "with" ones would...  unless we decided to
> >>make them all go away.  There might be sane reasons for doing that with
> >>"with", but I'm not sure those reasons apply to "except".
> >
> >We can allow tuples for 'except' at the grammar level, same as 'with';
> >it's just that anyone trying it would get the usual "TypeError: unpack
> >non-sequence" since the exceptions-as-sequence behaviour is going
> >away.
>
> Well, people can easily put it back in if they want; all that's required is
> an __iter__ method, after all.

Ow, you're right. But let's not encourage that.

> I'm talking about the consequences of allowing it at the grammar level,
> such as the need to explain why "except foo as (a,b)" does different things
> to the names than "except foo as ab".
>
> Unless, of course, we're going to say that "except foo as (a,b)" makes 'a'
> and 'b' disappear outside the block.

I like what we have at the grammar level now (in the p3yk branch):
only a single name is allowed. If you want to unpack it into something
else, you'll have to do the tuple-unpack inside the except clause.
Makes sense to me...

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)