[issue23720] __del__() order is broken since 3.4.0

Changes by Terry J. Reedy : -- nosy: -terry.reedy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail

[issue23720] __del__() order is broken since 3.4.0

Changes by Raymond Hettinger : -- assignee: -> pitrou priority: normal -> low resolution: -> not a bug ___ Python tracker ___ ___ Py

[issue23720] __del__() order is broken since 3.4.0

Terry J. Reedy added the comment: While this is not a bug, Antoine said he might look at improving the situation, so I leave it to him to close it or not. -- nosy: +terry.reedy stage: -> needs patch type: behavior -> performance versions: -Python 3.4 _

[issue23720] __del__() order is broken since 3.4.0

Raymond Hettinger added the comment: Can this be closed as not-a-bug. -- nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list

[issue23720] __del__() order is broken since 3.4.0

Serhiy Storchaka added the comment: Yes, in bug2.py we have different cycle. a ↔ b ↓ ↓ v → d a and b are in a cycle, and therefore v and d are in cycle. I think that in such case v always should be destroyed before d, independently of a cycle that refers them. And this is the same situation

[issue23720] __del__() order is broken since 3.4.0

Martin Panter added the comment: But in the case of bug2.py, “a” is a variable inside main(), not a global variable. BTW I take back my second paragraph questioning the whole order thing; I clearly didn’t think that one through. -- ___ Python track

[issue23720] __del__() order is broken since 3.4.0

Serhiy Storchaka added the comment: > There is a cycle involving the class object, but I don’t think there is a > cycle involving the instance objects this time. It is. >>> a = A() >>> a.__class__.__del__.__globals__['a'] <__main__.A object at 0xb702230c> And all objects referenced from user

[issue23720] __del__() order is broken since 3.4.0

Changes by Antoine Pitrou : -- nosy: +tim.peters ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue23720] __del__() order is broken since 3.4.0

Antoine Pitrou added the comment: Alexey, you're right that in this case (bug2.py) the cyclic GC is a bit less friendly than it was. It's not obvious there's a way to change that without introduce a lot of complexity. I'll try to take a look some day, although others may help too :-) That sai

[issue23720] __del__() order is broken since 3.4.0

Martin Panter added the comment: There is a cycle involving the class object, but I don’t think there is a cycle involving the instance objects this time. However, I wonder if __del__() is meant to be called in any particular order anyway. What’s to stop the garbage collector itself from creat

[issue23720] __del__() order is broken since 3.4.0

Serhiy Storchaka added the comment: There is a cycle for every class with a method. >>> class A: ... def __del__(self): pass ... >>> A.__del__.__globals__['A'] -- nosy: +serhiy.storchaka ___ Python tracker _

[issue23720] __del__() order is broken since 3.4.0

Alexey Kazantsev added the comment: Ok, even assuming that all module globals are in circular reference starting with python 3.4, here is another example without using the globals: Brief description: v holds reference to d a.v = v b.d = d Now when we form a circular reference a <-> b, the destr

[issue23720] __del__() order is broken since 3.4.0

Antoine Pitrou added the comment: Amaury is right. In your case you could keep track of the Vectors in the Device object and invalidate them when the Device is destroyed (using e.g. a WeakSet). Or Vector could delegate its destruction to Device, e.g.: class Device(object): destroy

[issue23720] __del__() order is broken since 3.4.0

Changes by Amaury Forgeot d'Arc : -- nosy: +pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail

[issue23720] __del__() order is broken since 3.4.0

Amaury Forgeot d'Arc added the comment: Actually there *is* a cycle: assert a.vector is a.vector.device.__class__.__del__.__globals__['a'].vector A workaround is to not store objects with __del__ in module globals... Or have only one (the Main instance in your case) -- nosy: +amaury.f

[issue23720] __del__() order is broken since 3.4.0

Vadim Markovtsev added the comment: +1 -- nosy: +Vadim Markovtsev ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe

[issue23720] __del__() order is broken since 3.4.0

New submission from Alexey Kazantsev: Pythons prior to 3.4.0 print Vector! Device! while >=3.4.0 print Device! Vector! If we replace Main with Vector on line 21, the behavior becomes random: in 50% of all cases it prints the wrong sequence, in other 50% the right. Our team treats this as a

[issue23720] __del__() order is broken since 3.4.0

Changes by Alexey Kazantsev : -- components: +Interpreter Core ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: