[Python-ideas] Sublocal scoping at its simplest
Nick Coghlan
ncoghlan at gmail.com
Sun Apr 29 07:39:45 EDT 2018
On 29 April 2018 at 21:24, Chris Angelico <rosuav at gmail.com> wrote:
> On Sun, Apr 29, 2018 at 6:03 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > The challenge with doing this implicitly is that there's no indication
> > whatsoever that the two "e"'s are different, especially given the
> > longstanding precedent that the try/except level one will overwrite any
> > existing reference in the local namespace.
>
> My intention is that the "except" statement IS the indication that
> they're different. Now that the name gets unbound at the exit of the
> clause, the only indication that it overwrites is that, after "except
> Exception as e:", any previous e has been disposed of. I'd hardly call
> that a feature. Can you show me code that actually DEPENDS on this
> behaviour?
>
That's not the bar the proposal needs to meet, though: it needs to meet the
bar of being *better* than the status quo of injecting an implicit "del e"
at the end of the suite.
While the status quo isn't always convenient, it has two main virtues:
1. It's easily explained in terms of the equivalent "del" statement
2. Given that equivalence, it's straightforward to avoid the unwanted side
effects by either adjusting your exact choices of names (if you want to
avoid overwriting an existing name), or else by rebinding the caught
exception to a different name (if you want to avoid the exception reference
getting dropped).
I do agree that *if* sublocal scopes existed, *then* they would offer a
reasonable implementation mechanism for block-scoped name binding in
exception handlers. However, exception handlers don't offer a good
motivation for *adding* sublocal scopes, simply because the simpler
"implicitly unbind the name at the end of the block" approach works well
enough in practice.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180429/af7061aa/attachment.html>
More information about the Python-ideas
mailing list