[pypy-dev] Compat. in 1.4.1 __del__

Christian Tismer tismer at stackless.com
Sat Feb 5 23:09:19 CET 2011


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 at 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/




More information about the Pypy-dev mailing list