[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.


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-3000 mailing list