RFC: Proposal: Deterministic Object Destruction

Ned Batchelder ned at nedbatchelder.com
Sat Mar 3 12:26:09 EST 2018


On 2/28/18 6:53 PM, ooomzay at gmail.com wrote:
> On Wednesday, February 28, 2018 at 11:45:24 PM UTC, ooo... 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:
>>> [snip]
>>> 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"
> Oh... I now see there is a (non-weak) self reference in there.
>
> So in this case it would be orphaned. It is a design error and should be recoded. I don't care how it is detected for current purposes.

There are many ways to create a cycle. You can't simply dismiss them all 
as design errors and put the burden on the developer to rewrite their code.

For example, objects have a reference to their classes.  So any time you 
write a class that references its objects, you have a cycle.  Or perhaps 
you have a tree structure where nodes have a list of their children, but 
also children have a reference to their parent?  I'm not even sure where 
in the inner workings of Python there are cycles.

There's a reason Python doesn't guarantee synchronous execution of 
__del__.  If you want your proposal to be taken seriously, you need to 
understand that reason, and propose a realistic alternative.

--Ned.



More information about the Python-list mailing list