Okay, sorry, I was thinking too Jython-like. I fixed runGC() just to see now that it does not even trigger resurrection, since under CPython there are no finalizers executed in ref cycles (i.e. I find my objects in gc.garbage). So I realize, my xy_cyclic tests are pointless anyway since in cyclic gc no resurrection can happen.

The second problem (with weakref) is different: weakrefs are cleared before __del__ is called, so resurrection doesn't affect the whole process. It appears weakrefs are only cleared if this is done by gc (where no resurrection can happen anyway). If a resurrection-performing-__del__ is just called by ref-count-drop-to-0, weakrefs persist - a behavior that is very difficult and inefficient to emulate in Jython, but I'll give it some more thoughts...

However thanks for the help! -Stefan

Gesendet: Sonntag, 26. Oktober 2014 um 01:22 Uhr Von: "Antoine Pitrou" An: python-dev@python.org Betreff: Re: [Python-Dev] results of id() and weakref.getweakrefs() sometimes break on object resurrection

Hello Stefan,

On Sun, 26 Oct 2014 00:20:47 +0200 "Stefan Richthofer" wrote:

...

Hello developers,

I observed strange behaviour in CPython (tested in 2.7.5 and 3.3.3) regarding object resurrection.

Your runGC() function is buggy, it does not run the GC under CPython. Fix it and the first problem (with id()) disappears.

The second problem (with weakref) is different: weakrefs are cleared before __del__ is called, so resurrection doesn't affect the whole process. Add a callback to the weakref and you'll see it is getting called.

In other words, CPython behaves as expected. Your concern is appreciated, though.

Regards

Antoine.

_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/stefan.richthofer%40gmx.d...

On Saturday, October 25, 2014, Stefan Richthofer wrote:

Okay, sorry, I was thinking too Jython-like. I fixed runGC() just to see now that it does not even trigger resurrection, since under CPython there are no finalizers executed in ref cycles (i.e. I find my objects in gc.garbage). So I realize, my xy_cyclic tests are pointless anyway since in cyclic gc no resurrection can happen.

...

The second problem (with weakref) is different: weakrefs are cleared before __del__ is called, so resurrection doesn't affect the whole process. It appears weakrefs are only cleared if this is done by gc (where no resurrection can happen anyway). If a resurrection-performing-__del__ is just called by ref-count-drop-to-0, weakrefs persist - a behavior that is very difficult and inefficient to emulate in Jython, but I'll give it some more thoughts...

You shouldn't have to emulate that. The exact behavior of GC is allowed to vary between systems.

However thanks for the help!

-Stefan

...

Gesendet: Sonntag, 26. Oktober 2014 um 01:22 Uhr Von: "Antoine Pitrou" javascript:;> An: python-dev@python.org javascript:; Betreff: Re: [Python-Dev] results of id() and weakref.getweakrefs() sometimes break on object resurrection

Hello Stefan,

On Sun, 26 Oct 2014 00:20:47 +0200 "Stefan Richthofer" javascript:;> wrote:

...

Hello developers,

I observed strange behaviour in CPython (tested in 2.7.5 and 3.3.3) regarding object resurrection.

Your runGC() function is buggy, it does not run the GC under CPython. Fix it and the first problem (with id()) disappears.

The second problem (with weakref) is different: weakrefs are cleared before __del__ is called, so resurrection doesn't affect the whole process. Add a callback to the weakref and you'll see it is getting called.

In other words, CPython behaves as expected. Your concern is appreciated, though.

Regards

Antoine.

_______________________________________________ Python-Dev mailing list Python-Dev@python.org javascript:; https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/stefan.richthofer%40gmx.d...

_______________________________________________ Python-Dev mailing list Python-Dev@python.org javascript:; https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org

-- --Guido van Rossum (on iPad)

Hi Stefan, On 26 October 2014 02:50, Stefan Richthofer wrote:

It appears weakrefs are only cleared if this is done by gc (where no resurrection can happen anyway). If a resurrection-performing-__del__ is just called by ref-count-drop-to-0, weakrefs persist -

How do you reach this conclusion? The following test program seems to show the opposite, by printing None on Python 2.7.6: import weakref class X(object): def __del__(self): print ref() x = X() ref = weakref.ref(x) del x A bientôt, Armin.

On Mon, 27 Oct 2014 14:36:31 +0100 Stefan Richthofer wrote:

Your test program performs no resurrection of x.

Interestingly, it does not change behavior if you write

class X(object): def __del__(self): X.x = self print ref()

(Thanks for making me aware of this! My test-case was already initially the more complex one given below)

But if the resurrection occurs indirectly, the weakref persists:

It's not that resurrection occurs indirectly, it's that the object pointed to by "x2" always remains alive (first as an instance attribute of x, second as a class attribute of X *before x is deleted*). Regards Antoine.

On Mon, 27 Oct 2014 16:20:06 +0100 Stefan Richthofer wrote:

I already pointed out "One can surely argue x2 has never been dead, or see it as "it was killed along with x and then resurrected by x"."

In Java and thus in Jython, it is treated as the second one.

You mean Jython deletes instance attributes before calling __del__ ? That would make most __del__ implementations quite useless... And actually your own example would fail with an AttributeError on "X.y = self.z".

What would still be interesting (at least when Jython 3 is born), is which of the mentioned behaviors occurs if it is performed by CPython's cyclic gc (consistently the first one I would guess).

In which use case exactly? :-) I've lost track a bit, since you've posted several examples... Regards Antoine.