On 18Nov2020 08:34, Steven D'Aprano <steve@pearwood.info> wrote:
As far as shadowing other variables, if someone has so much code in their function, or at the top level, that they are at risk of inadvertantly shadowing variables, they have far more serious problems than the use of the conventional "e for exception".
To start with, what else are they using "e" for? Surely it would be more important to use a better name *there* rather than change the exception variable.
Aye, that was my thought too. Avoiding a collision is so easy that adding a magic special scope to Python seems overkill. I'm also against lots of scopes. They cause pain. I wrote a post in (I thought) a Python discussion about adding more scopes citing what I consider a horrible flaw in Go's scope design which shadows the common "err" return from various calls (Go doesn't use exceptions), and provided a code example of how easy it was to accidentally break one's error handling because of that design. Annoyingly, I cannot find that post now. But basicly the if-statement introduces a scrope (which starts at the test, before the {...} brackets) while shadows an earlier variable, and on exiting the scrope the common "err" variable is False again, indicating no error. Really irritating. Cheers, Cameron Simpson <cs@cskk.id.au>