RFC: Proposal: Deterministic Object Destruction
On Thu, Mar 1, 2018 at 10:44 AM, <ooomzay at gmail.com> wrote:
> On Wednesday, February 28, 2018 at 11:02:17 PM UTC, Chris Angelico wrote:
>> On Thu, Mar 1, 2018 at 9:51 AM, ooomzay wrote:
>> > Specification
>> > =============
>> > When the last reference to an object goes out of scope the intepreter must synchronously, in the thread that releases the last reference, invoke the object's __del__() method and then free the memory occupied by that object.
>> If it were that simple, why do you think it isn't currently mandated?
> We know the implementation is feasible because CPython, the reference interpreter implementation, already does this. I am guessing that there is a lobby from garbage platforms where it would be harder to implement and integrate however the object of this proposal is the integrity of the language, not on making it easier to implement using garbage platforms.
Good to know that Jython and friends are "garbage platforms". I hope
you were referring to garbage collection, and that this was merely a
clumsy choice of words, rather than actually insulting these other
>> Here's one example: reference cycles. When do they get detected?
> Orphan cycle _detection_ is orthogonal to this proposal. As cycles are always a symptom of a design error I personally have little interest in them other than some facility to detect/debug and eliminate them from applications by design (another topic).
No, they're not always a symptom of a design error.
>> Taking a really simple situation:
>> class Foo:
>> def __init__(self):
>> self.self = self
>> print("Creating a Foo")
>> def __del__(self):
>> print("Disposing of a Foo")
>> foo = Foo()
>> foo = 1
>> When do you expect __del__ to be called?
> At the point of (re)assignment: "foo = 1"
>> How do you implement this efficiently and reliably?
> CPython already has a reliable and reasonably efficient implementation based on reference counting.
Just before reassignment, there are two references to that object: one
from the name "foo", and another from its own "self" attribute. After
reassignment, there is one reference, from its own "self" attribute.
The reference count will never drop to zero.
I suggest you read up on why other forms of garbage collection exist,
rather than simply demanding that Python behave in a particular way.