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

[Richard Damon]

On 3/3/18 6:57 PM, Steven D'Aprano wrote:
> 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.
>
>
If checking for a method definiton is that slow, it wouldn't work. The 
idea was to have a way to mark that certain classes/objects request that 
they are reference counted so they get the __del__ called as soon as the 
last reference goes away, without needing to require that overhead for 
all objects in all implementations.

-- 
Richard Damon