I think Python's rules about what constitutes a new scope are a touch inconsistent--or, as the Zen might put it, "practical".

First, simple statements never create their own scope. That's easy. Second, compound statements that create a new function, "def" and "lambda", always create a new scope. "class" also creates a new scope, but that's intuitive--and if you understand the language you know that under the hood it's also creating a code object like "def" and "lambda" do. Anyway, none of the other "compound" statements create scopes. That's true even for compound statements that themselves make assignments, like "for", "with", and "except". But you'll note they also don't create new code objects. Finally, we note that modules always have their own scopes. And again, if you understand the language, you know they're also implemented using code objects.

If that was the whole list, then the mental model would be super simple: code objects always create their own scopes, and nothing else does.

But then we get to generator expressions and list/dict/set comprehensions. I think of those as doing an "assignment", but I have to remember the assignment "doesn't leak":

x = 3
y = list(x**2 for x in range(5))
print(f"{x=}")

This code prints "x=3".

Why this exception to the rule? IIRC from the discussions back when they were added, this one of those "it just seemed best at the time" things. "for" was added to the language long before I got there, but it "leaking" its assignment was judged useful; if you broke out of the loop, you could continue to examine the last value from the loop. But, the thinking went, you'd never want to examine the last value from a list generator, so it was more convenient if it behaved as if it had its own scope.

/arry

p.s. Maybe I should be using the word "binding" instead of "assignment"? If there's an important distinction between the two terms I don't know it.

On 11/17/20 1:55 AM, Mark Shannon wrote:

Hi,

I'm wondering why
```
x = "value"
try:
    1/0
except Exception as x:
    pass
```

does not restore "value" to x after
the `except` block.

There doesn't seem to be an explanation for this behavior in the docs or PEPs, that I can find.
Nor does there seem to be any good technical reason for doing it this way.

Anyone know why, or is just one of those unintended consequences like `True == 1`?

Here's an example of restoring the value of the variable after the `except` block:

>>> def f(x):
...     try:
...         1/0
...     except Exception as x:
...         pass
...     return x
...
>>> f("hi")
'hi'

Cheers,
Mark.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/KGYRLITEPB22ZZO4N7DD4A7QP7FQS6JO/
Code of Conduct: http://python.org/psf/codeofconduct/