RFC: Proposal: Deterministic Object Destruction
On 3/4/18 8:46 AM, Chris Angelico wrote:
> On Mon, Mar 5, 2018 at 12:26 AM, Ooomzay <ooomzay at gmail.com> wrote:
>> Well refcounts are definitely "doable": This is how the reference python implementation, CPython, currently manages to comply with this PEP and can
>> therefore be used for RAII.
>> This PEP is an attempt to _guarantee_ this behaviour and make the elegance
>> of RAII available to all pythonistas that want it. Without this guarantee
>> python is not attractive to applications that must manage non-trivial
>> resources reliably.
>> Aside: I once read somewhere that must have seemed authoritative at the
>> time, that CPython _guarantees_ to continue to behave like this - but now the subject is topical again I can find no trace of this guarantee.
> That's because there is no such guarantee. In fact, you can probably
> find places in the docs where it is specifically stated that you
> cannot depend on __del__ for this.
> You still haven't said how you're going to cope with reference cycles
> - or are you expecting every single decref to do a full cycle check?
My presumption of the proposal is the it does NOT expect that __del__ be
called just because an object is no longer reachable but is in a cycle
of isolated objects, those would still need to wait for the garbage
collector to get them. The request is that when the direct reference
count goes to 0, that __del__ gets called.
I think that is what CPython promises (but not other versions).
I am not positive if __del__ gets called for sure when the object is
garbage collected (I thought it did, but I am not positive).
I am pretty sure it does NOT get called on object that are still in
existence when things terminate (which would be the major difference
from a language like C++)
What the language does not promise is that in general, __del__ be called
'immediately' on the last reference going away in the general case,
because CPythons reference counting is an implementation detail.
My understanding of this proposal is to ask that, I would say at least
for selected objects, that all implementations perform this reference
counting, allowing objects that track 'critical resources' to get
disposed of in a timely manner and not wait for garbage collection. And
that this is triggered only by the reference count going to zero, and
not if the object happens to be in an isolated reference cycle. This
does limit what you can do with this sort of object, but that normally
isn't a problem.