On 18Nov2020 08:34, Steven D'Aprano <[email protected]> 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 <[email protected]>
_______________________________________________
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/OFIF36EACAW5F4OBY7H6JXFQRVGZKKN6/
Code of Conduct: http://python.org/psf/codeofconduct/
