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