RFC: Proposal: Deterministic Object Destruction (Posting On Python-List Prohibited)

[Steven D'Aprano]

On Sat, 03 Mar 2018 10:01:43 -0700, Ian Kelly wrote:

> On Sat, Mar 3, 2018 at 9:19 AM, Richard Damon <Richard at damon-family.org>
> wrote:
>> One idea does come to mind though, would it be reasonable, and somewhat
>> Pythonic, for a class to define member functions like __ref__ and
>> __unref__ (or perhaps some other name) that if defined, would be called
>> every time a name was bound or unbound to an object? (the assignment to
>> a name should __ref__ the new value, then __unref__ the old to avoid
>> possible issues with rebinding an object to the last name it was bound
>> to). This would allow those (limited) objects that want to be destroyed
>> as soon as possible to do so, but most other objects wouldn't have any
>> significant overhead added (just a check for this method).
>>
>> Objects with these methods would still be subject to being cleaned up
>> with garbage collection in the case they were kept alive via a cycle,
>> having the cycle just makes it so that you don't get the immediate
>> distruction.
> 
> This sounds like a nightmare for performance. Ref counting is enough of
> a drain already when it's done in C, using macros for in-lining. Now
> every time the count would be incremented or decremented, we'd also need
> to check the class __dict__ to see if there's a corresponding Python
> method, build a frame object, and then call it in the interpreter.

Not just the class __dict__. You would have to do a full search of the 
MRO looking for any superclass which defines such methods.

Python code doesn't tend to go in for long inheritance hierarchies, but 
still, you could easily be checking four or five classes on *every* 
binding.

Richard's assertion that this wouldn't add significant overhead isn't 
right.

[...]
> It would be much more efficient to spare all that by doing the
> ref-counting in the interpreter and just call a method when it hits
> zero. Which is just what CPython already does.

Indeed.

I'm afraid I don't understand what Richard's proposal is actually meant 
to do. It sounds to me like he's just proposed adding a second, parallel, 
optional, *SLOW* reference counter to the CPython implementation, in 
order to force non-ref counter implementations to do something which they 
have no need to do.


-- 
Steve