[Python-3000] Removing __del__
Nick Coghlan
ncoghlan at gmail.com
Fri Sep 22 13:02:38 CEST 2006
Marcin 'Qrczak' Kowalczyk wrote:
> "Giovanni Bajo" <rasky at develer.com> writes:
>
>> What if the "self" passed to __del__ was instead a weakref.proxy,
>> or a similar wrapper object which does not give you access to the
>> object itself but lets you access its attributes?
>
> weakref.proxy will find the object already dead.
>
> I doubt this can be done fully automatically.
>
> The basic design is splitting the object into an outer part handled to
> clients, which is watched to become unreachable, and a private inner
> part used to physically access the resource, including releasing it.
> I see no good way around it.
>
> Often the inner part is a single field which is already separated.
> In other cases it might require an extra indirection, in particular
> if it's a mutable field.
>
> This design distinguishes between related objects which are needed
> during finalization (fields of the inner object) and related objects
> which are not (fields of the outer object).
>
> Cycles involving only outer objects are harmless, they can be safely
> freed together, triggering finalization of all associated objects.
> Inner objects may also refer to most other objects, ensuring that
> they are not finalized earlier. But a path from an inner object to its
> associated outer object prevents it from being finalized and is a bug
> in the program (unless it is broken before the object loses all other
> references).
Exactly. My strawman design made the default inner object a simple class with
the same instance dictionary as the outer object so that most current __del__
implementations would 'just work', but it poses the problem of making it easy
to inadvertently create an immortal cycle.
OTOH, that can already happen today, and the __del_arg__ mechanism provides an
easy way of ensuring it doesn't happen.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
More information about the Python-3000
mailing list