On Thu, May 28, 2020 at 10:42 AM Rob Cliffe <rob.cliffe@btinternet.com> wrote:

On 26/05/2020 20:03, Chris Angelico wrote:

...

On Wed, May 27, 2020 at 2:51 AM Steven D'Aprano <steve@pearwood.info> wrote:

...

But doing otherwise, having Undef be *not an object* but a kinda ghost in the interpreter, is a huge language change and I doubt it would be worth it.

But is it a huge change? I thought so too, until Greg suggested a quite plausible option: leave the local unbound. There'd be two changes needed, and one of them could have other value. The semantics would be exactly the same as any other unbound local.

def foo(): if False: x = 0 # what is x now?

There is no *value* in x, yet x has a state. [snip] Sorry, I don't think it does. It's not in locals(), it doesn't exist anywhere in memory. It might be created later in foo(), but it would then have a value.

It is in the state of being unbound, and you can prove this by attempting to print it out.

...

...

foo() Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 3, in foo UnboundLocalError: local variable 'x' referenced before assignment

This is NOT the same as if the assignment hadn't been in the code (which would have gone looking for a global or builtin x). So yes, it does have a state. ChrisA