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

[Chris Angelico]

On Sun, Mar 4, 2018 at 3:19 AM, Richard Damon <Richard at damon-family.org> wrote:
> On 3/3/18 9:03 AM, Ian Kelly wrote:
>>
>> On Fri, Mar 2, 2018 at 9:57 PM, Gregory Ewing
>> <greg.ewing at canterbury.ac.nz> wrote:
>>>
>>> Paul Rubin wrote:
>>>>
>>>> So you want the programmer to put more head scratching into figuring out
>>>> which reference should be strong and which should be weak?
>>>
>>>
>>> Also, sometimes weak references don't really solve the
>>> problem, e.g. if you have a graph where you can't identify
>>> any particular node as a "root" node, and you want the graph
>>> to stay around as long as any of its nodes are referenced.
>>
>> I offered two possible solutions for the graph problem elsewhere in this
>> thread.
>>
>> For the record I'm not in favor of the OP's proposal (although making
>> the different Python implementations more consistent in their garbage
>> collection semantics would not be a bad thing per se) but I am
>> somewhat mystified as to why people seem to think that weak refs are
>> difficult to use correctly.
>
>
> As I think about this, and coming from a background where I have found the
> ability to reliably use RAII useful in some cases, I can see some merit to
> the proposal. One big issue is that since Python doesn't have sub-function
> level lifetime scopes for locals, it is perhaps not quite as useful in some
> cases.
>
> 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.

I'm not sure what __unref__ gives you that __del__ doesn't, aside from
mandating that every Python implementation from here to eternity MUST
use reference counting.

ChrisA