On Tue, Jul 25, 2017 at 6:10 PM, Ben Finney <ben+pyt...@benfinney.id.au> wrote:
> I think those are not the only two options (the “except clause has its
> own scope” behaviour is an option that could have been chosen, for
> example).
>
> At this point the behaviour and motivation are clear, having been
> revealed; I disagree with the behaviour, and think the motivation could
> have been met better.
Having a new scope introduced by a non-function would also be
surprising. List comprehensions (as of Py3) introduce a new scope, but
they do so by being wrapped in a function. Would you expect that an
except block is wrapped in a function too? And whether or not it's a
function, the fact would remain that except blocks would differ from
other name-binding blocks (with/as and for). There's a reasonable
argument for with/as to introduce a new scope, but a for loop
definitely shouldn't, so there's going to be a difference there.
And if it's its own function, you'd need to use nonlocal/global inside
it to make any other changes. That would be a royal pain. Consider:
try:
raw_input
except NameError:
global raw_input # blech
raw_input = input
I'm not actually sure what happens if you use a global declaration at
top level. Is it ignored? Is it an error?
One potential solution would be to have *just the exception name* in a
sort of magic scope. But I'm not sure how that would go.
TBH, I rather suspect that the exact semantics here aren't too
critical. If there's a solid argument for some variation on the
current system, one that still prevents the refloop between the
exception and a function's variables, it'd be worth discussing as a
proposal. At very least, it's worth raising it on -ideas... worst
case, it gets shut down quickly.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
