Lifetime of a local reference
roel at roelschroeven.net
Thu Feb 28 15:23:41 EST 2019
Rhodri James schreef op 28/02/2019 om 13:09:
> On 27/02/2019 21:39, Roel Schroeven wrote:
>> Rhodri James schreef op 27/02/2019 om 15:18:
>> Aren't we overthinking this?
>> I think it's pretty clear that a variable is never deleted before it
>> goes out of scope. A quick search in the documentation points me to
>> "Objects are never explicitly destroyed; however, when they become
>> unreachable they may be garbage-collected. An implementation is allowed
>> to postpone garbage collection or omit it altogether — it is a matter of
>> implementation quality how garbage collection is implemented, *as long
>> as no objects are collected that are still reachable*." (emphasis mine)
>> In the original example (without del), f is reachable everywhere in the
>> function after the initial binding, so it can not be deleted.
>> Comparisons with C on this point don't seem very relevant: C doesn't
>> have destructors or garbage collection. I don't even see what the C
>> equivalent for "del f" could be. You could perhaps compare with C++,
>> where destructors are also not called before the object goes out of
>> scope (a difference is that in C++ the destructor explicitly always is
>> called at that moment).
> I think you're making the mistake of equating names ("variables") and
> objects here.
Yes, on second reading that quote from the documentation is not very
> It is not clear to me that a name can't be removed from
> the dictionary of locals before it goes out of scope, so long as it
> doesn't get referred to again,
It is said that an assignment binds a name to an object in the current
local namespace (if there is no 'global' or 'nonlocal'). It is said that
deletion (the del statement) of a name removes the binding of that name
from the local namespace (again, if there is no 'global' or 'nonlocal').
In the absence of any other mention of bindings being removed, to me it
seems clear that bindings are not automatically removed. Otherwise many
things become ambiguous. Example: the documentation for dicts defines
"d[key] = value" as "Set d[key] to value". Does that mean it can get
unset later behind your back? Of course not.
> just like C optimisers can note that a
> local doesn't get used again and reclaim the storage. At that point the
> object can become unreachable, and will in Marko's example.
> The equivalent to "del f" that you can't imagine is the optimiser at work.
But note that reclaiming storage in C has no side effects. No locks are
released, no files are closed. No destructor is run, since C has no such
thing. It's purely an implementation detail. As long as the visible
behavior of the program complies with the language specification, the
compiler can do as it wishes. In C's relative C++, variables going out
of scope *do* have side effects, and there it *is* guaranteed that that
only happes at the end of the scope (however the compiler sees fit to
(Also note that the concept of "unreachable" does not exist in C; C does
not have names and objects like Python).
Python's "del" on the other hand most certainly has a visible effect. It
is not purely an implementation detail.
"Honest criticism is hard to take, particularly from a relative, a
friend, an acquaintance, or a stranger."
-- Franklin P. Jones
More information about the Python-list