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

AltStyle によって変換されたページ (->オリジナル) /