Howdy, studying the differences of PyPy vs. CPython, most seem to be fine; one thing where I an unsure is the __del__ behavior. I am not addressing its delayed call or the number it is called, this is similar to Jython and IronPython. But assigning to __del__ after a class is created, is that so hard to implement? It is clear to me that the existence of a __del__ heavily influences the whole code generation of a class. So as a naive thought, can we just abandon the whole compilation and start over (maybe even less)? The problem that I see is re-generation of already created instances, triggering some re-compilation. I would think of all compiled code always going through some "fuse code" that would trigger re-compilation if an assignment to __del__ happens. For me, this looks like a guard, that exists in other places of the JIT, where existing assumptions must check if they are still true, and otherwise start over. I have not read the current implementation, yet, because my reading is still quite impaired. But from the top of my head: Can it be that such a re-compile as I mentioned is not yet considered because that is not involving the JIT, but an already fixed part of the static compilation chain? I think not, since we are not in RPython, but at the translation of an applevel class, which is completely run-time compiled. So, where is my lack of seeing the problem? Or is it simply a lot of effort? If it is an efficiency concern, then my POV is: Better to be slow in a few cases of re-compilation, than to have to hunt for such delicate existing code. I would instead issue an optional warning to dynamic __del__ assignment instead, in order to let people avoid it in the future. regards, and thanks for correcting me - chris -- Christian Tismer :^)<mailto:tismer@stackless.com> tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/