On 1/6/19 9:14 AM, Steven D'Aprano wrote: > [...] > But a better question is, why would you (generic, not you personally) > imagine that, alone out of all flow control statements, ONLY "except" > clauses introduce a new scope? Every other flow control statement (for, > while, if, elif, else, try, with) runs in the current scope. The only > statements which create a new scope are def and class. (Did I miss any?)
To be fair except is already unique in that it /does/ "pseudo-scope" the binding to the variable. The other obvious comparisons are to for loops and context managers, both of which bind a value to a name that survives after the exit of the control flow statement. Given the reference counting reasons for exceptions *not* to outlive their control flow statement, they are the "odd man out" in that they delete the exception after the control statement's body exits. To me, the natural and intuitive way to do this would be to have the exception live in its own scope where it shadows existing variables, rather than replacing and then completely removing them. The way it works now is halfway between the behavior of existing control flow statements and having a proper nested scope. Not saying that anything has to change - in the end this is one of the more minor "gotchas" about Python, and there may be practical reasons for leaving it as it is - but I do think it's worth noting that for many people this /will/ be surprising behavior, even if you know that exceptions don't survive outside of the "except" block.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
