4 ms·

> Oddly enough It's not that odd, since it's the only situation where you cannot keep it bounded, unless you enjoy having variables that may or may not be defi

> Oddly enough It's not that odd, since it's the only situation where you cannot keep it bounded, unless you enjoy having variables that may or may not be defined (Heisenberg variable?), depending on whether the exception has been raised or not? Compare with the if statement, where the variable in the expression being tested will necessarily be defined.

NekkoDroid 1y ago
While somewhat true, what would this be bound to? for i in range(0): pass
- suspended_state 1y ago
  Well, after writing my comment, I realized that a python interpreter could define the variable and set it to None between the guarded block and the except block, and implicitly assign it to the raised exception right before evaluating the except block, when the exception as been raised. So technically, it would be possible to define the variable e in GP example and have it scoped to "whatever is after the guarded block", just like what is done with for blocks. Is there any chance this would cause trouble though? Furthermore, what would be the need of having this variable accessible after the except block? In the case of a for block, it could be interesting to know at which point the for block was "passed". So, maybe "None" answers your question?
  - NekkoDroid 1y ago
    The answer is: it is unbound. Intellisense will most likely tell you it is `Unbound | <type>` when you try to use the value from a for loop. Would it be possible that it could be default initialized to `None`? Sure, but `None` is a destinctivly different value than a still unbound variable and may result in different handling.
MyOutfitIsVague 1y ago
> Compare with the if statement, where the variable in the expression being tested will necessarily be defined. if False: x = 7 print(x) print(x) ^ NameError: name 'x' is not defined Ruby does this sort of stuff, where a variable is defined more or less lexically (nil by default). Python doesn't do this. You can have local variables that only maybe exist in Python.
fuzztester 1y ago
Heisenbug is the word you are looking but may not find.
nomel 1y ago
Are you saying that this should result in a name error? if <true comparison here>: x = 5 print(x) # <- should give name error?
- suspended_state 1y ago
  I stand corrected, the exception case is definitely an oddity, both as being an outlier and as a strange behaviour wrt Python's semantics. Or is it a strange behaviour? In the case of an if like in your example, no provision is made about the existence of x. It could have been defined earlier, and this line would simply update its value. Your example: if True: x = 5 print(x) # 5 Same with x defined prior: x = 1 if False: x = 5 print(x) # 1 What about this one? if False: x = 5 print(x) # ??? On the other hand, the notation "<exception value> as <name>" looks like it introduces a new name; what if that name already existed before? Should it just replace the content of the variable? Why the "as" keyword then? Why not something like "except <name> = <exception value>" or the walrus operator? While investigating this question, I tried the following: x = 3 try: raise Exception() except Exception as x: pass print(x) # <- what should that print?
- fc417fc802 1y ago
  In any sane language it would, yes.

NekkoDroid 1y ago

While somewhat true, what would this be bound to? for i in range(0): pass

suspended_state 1y ago
Well, after writing my comment, I realized that a python interpreter could define the variable and set it to None between the guarded block and the except block, and implicitly assign it to the raised exception right before evaluating the except block, when the exception as been raised. So technically, it would be possible to define the variable e in GP example and have it scoped to "whatever is after the guarded block", just like what is done with for blocks. Is there any chance this would cause trouble though? Furthermore, what would be the need of having this variable accessible after the except block? In the case of a for block, it could be interesting to know at which point the for block was "passed". So, maybe "None" answers your question?
- NekkoDroid 1y ago
  The answer is: it is unbound. Intellisense will most likely tell you it is `Unbound | <type>` when you try to use the value from a for loop. Would it be possible that it could be default initialized to `None`? Sure, but `None` is a destinctivly different value than a still unbound variable and may result in different handling.

MyOutfitIsVague 1y ago

> Compare with the if statement, where the variable in the expression being tested will necessarily be defined. if False: x = 7 print(x) print(x) ^ NameError: name 'x' is not defined Ruby does this sort of stuff, where a variable is defined more or less lexically (nil by default). Python doesn't do this. You can have local variables that only maybe exist in Python.

fuzztester 1y ago

Heisenbug is the word you are looking but may not find.

nomel 1y ago

Are you saying that this should result in a name error? if <true comparison here>: x = 5 print(x) # <- should give name error?

suspended_state 1y ago
I stand corrected, the exception case is definitely an oddity, both as being an outlier and as a strange behaviour wrt Python's semantics. Or is it a strange behaviour? In the case of an if like in your example, no provision is made about the existence of x. It could have been defined earlier, and this line would simply update its value. Your example: if True: x = 5 print(x) # 5 Same with x defined prior: x = 1 if False: x = 5 print(x) # 1 What about this one? if False: x = 5 print(x) # ??? On the other hand, the notation "<exception value> as <name>" looks like it introduces a new name; what if that name already existed before? Should it just replace the content of the variable? Why the "as" keyword then? Why not something like "except <name> = <exception value>" or the walrus operator? While investigating this question, I tried the following: x = 3 try: raise Exception() except Exception as x: pass print(x) # <- what should that print?
fc417fc802 1y ago
In any sane language it would, yes.