Python 3 removes name binding from outer scope

Ben Finney ben+python at benfinney.id.au
Tue Jul 25 04:10:00 EDT 2017


Steven D'Aprano <steve+comp.lang.python at pearwood.info> writes:

> On Tue, 25 Jul 2017 17:02:48 +1000, Ben Finney wrote:
>
> > I suppose my objection is rooted in the fact this behaviour is
> > implicit; my code has not issued a ‘del’ statement, and so I don't
> > expect one; yet it occurs implicitly. This violates the Zen of
> > Python.
>
> Technically, *all* garbage collection is implicit.

The surprising behaviour is not garbage collection; I hadn't noticed
anything different with garbage collection.

The surprising behaviour is the unasked-for removal of a name binding
from the context, that was bound earlier in the same context.

> So consider this as a de-facto "the except clause "as name" variable
> is treated *as if* it exists in its own scope.

It is not, though. “as if it exists in its own scope” would mean that it
should not affect the earlier binding in a different scope.

That's not what happens; an earlier binding is re-bound (explicitly, by
‘as target’) and then *implicitly* removed so the name is unbound.

> I agree that the behaviour of except is a little surprising, but
> that's (according to the core devs) the lesser of two evils. The
> alternative is a memory leak when the traceback keeps data alive that
> you didn't expect.

I think those are not the only two options (the “except clause has its
own scope” behaviour is an option that could have been chosen, for
example).

At this point the behaviour and motivation are clear, having been
revealed; I disagree with the behaviour, and think the motivation could
have been met better.

-- 
 \       “If you always want the latest and greatest, then you have to |
  `\          buy a new iPod at least once a year.” —Steve Jobs, MSNBC |
_o__)                                             interview 2006-05-25 |
Ben Finney




More information about the Python-list mailing list