No, since Python 2.0 cyclic references are collectable and will be garbage collected eventually. However, the __del__ method of the cyclic trash will not be executed as there is no way to do so consistently while all objects in the cycle are alive.
In Cython, the __dealloc__ method will be called, but with (partially) dead objects: Some of the objects in the reference cycle may have their Python attributes already cleared. In Python 3.4 (PEP 442) the __del__ method is called on all objects of the cycle first (in a random order), and then the objects are garbage collected. One quirk is that objects are resurrected if __del__ generates a new reference to the object, though I don't know if that applies here. On Saturday, January 31, 2015 at 9:35:12 PM UTC-5, Nils Bruin wrote: > > On Saturday, January 31, 2015 at 5:06:54 PM UTC-8, Volker Braun wrote: >> >> On Saturday, January 31, 2015 at 3:59:05 PM UTC-5, Jeroen Demeyer wrote: >>> >>> In any case: after removing __del__ from Expect and Interface, all >>> doctests pass, so it's not that bad. >>> >> >> Also __del__ is never going to be reliably called in the face of cyclic >> references, >> > > That is not true: In Python2, cycles with objects with __del__ methods in > them are not automatically deleted, so the methods are reliably *not* > called, because the objects aren't destructed. In Python3, it is guaranteed > that a __del__ method on an object is called at least once. If you do evil > stuff such as making the object reachable again in the __del__, then python > will prevent the cycle from being destructed, but now you're on your own > concerning the state in which your objects are (and it could happen that > the __del__ gets called again). > > so I'm all for taking it out. Cleanup should be done elsewhere (or do it >> in Cython __deallocate__ >> > > That will require careful design. By the time a __dealloc__ is executed, > the object is already torn down considerably, so just calling a method > ".quit()" on the object is not a good idea. I think Jeroen's suggestion of > somehow subclassing so that the object returned by Expect.spawn can do > proper tear-down (that probably means registering with it the strings that > should be sent to the interface to precipitate a tear-down) is a good idea. > These objects will be fairly limited, so guaranteeing they are not in > cycles won't be too bad. Then having a __del__ method to do the clean-up > there should be acceptable. > > Another workaround would be to put all the cleanup in a call-back of a > weakref, and store the weakref in a global dictionary somewhere. The > callback should of course not hold any strong references, but it will be > able to get a pointer to the original object via the weakref that is > available to the callback. Upon exit from the system there is of course no > guarantee that the weakref callback will get executed, because it might get > deleted before the interface. > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
