Marcin 'Qrczak' Kowalczyk wrote:
> "Giovanni Bajo" <[EMAIL PROTECTED]> 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 | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
