[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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?
> ChrisA

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.

Richard Damon