You are right, reference cycles with __del__ methods are treated
differently from reference cycles without __del__ methods. The former are
uncollectable in Python 2.
On Sunday, February 1, 2015 at 12:00:13 PM UTC-5, Nils Bruin wrote:
> So indeed, the running of __del__ methods is not guarantee
On Sunday, February 1, 2015 at 7:24:23 AM UTC-8, Volker Braun wrote:
>
> 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 obj
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 cal
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 t
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, so I'm all for taking it o
On Saturday, January 31, 2015 at 3:45:33 PM UTC-5, Jeroen Demeyer wrote:
>
> I have been thinking many times about rewriting pexpect from scratch and
> this would be yet another reason.
Some of the pty kernel bugs that I've seen tell me that this will be a
frustrating exercise...
--
You rec
I guess the easiest solution is probably to make a custom class deriving
from the pexpect "spawn" class to implement kill-on-del.
In any case: after removing __del__ from Expect and Interface, all
doctests pass, so it's not that bad.
--
You received this message because you are subscribed to
On 2015-01-31 21:26, Nils Bruin wrote:
I imagine that the __del__ kills the process that is being interfaced
That's true unfortunately. I would have expected the pexpect library to
do that, but it doesn't!! It's only Sage's quit() method which kills the
process.
I have been thinking many time
On Saturday, January 31, 2015 at 11:57:14 AM UTC-8, Jeroen Demeyer wrote:
>
> On 2015-01-31 19:22, Nils Bruin wrote:
> > Another is to put all the "__del__" code into a separate object that the
> > "parent" object holds a reference to, but that itself does not refer to
> > the parent. Then the _
On 2015-01-31 19:22, Nils Bruin wrote:
Another is to put all the "__del__" code into a separate object that the
"parent" object holds a reference to, but that itself does not refer to
the parent. Then the __del__-equipped object is not involved in a cycle.
Obvious question: do we need a custom _
On Saturday, January 31, 2015 at 9:15:33 AM UTC-8, vdelecroix wrote:
>
> I found out where it is. The Interface objects inherits from
> ParentWithBasis and the base is itself...
>
> sage: p = Gp()
> sage: p._base is p
> True
>
Hm, that's a problem. Parent objects are virtually always involved
I found out where it is. The Interface objects inherits from
ParentWithBasis and the base is itself...
sage: p = Gp()
sage: p._base is p
True
Now, setting _base to None, it gets deleted
sage: p._base = None
sage: del p
Vincent
--
You received this message because you are subscribed to the Goo
2015-01-31 18:05 UTC+01:00, Vincent Delecroix <20100.delecr...@gmail.com>:
> I am not sure where is
> this cycle with expect/Gp though.
And I am pretty sure there is one inside Gp itself since
sage: p = Gp()
sage: import gc
sage: any(id(x) == id(p) for x in gc.get_referrers(p))
True
--
You re
One possible issue is that an object that holds a reference to itself
and implement a __del__ method is not collected. Pick the minimal
example
sage: class A(object):
def __del__(self):
print "delete %d"%id(self)
sage: a = A()
sage: a.a = a
sage: del a
sage: gc.collect()
2
sage: gc.ga
14 matches
Mail list logo
