[pypy-dev] Compat. in 1.4.1 __del__

Christian Tismer tismer at stackless.com
Sun Feb 6 00:49:00 CET 2011

On 2/6/11 12:25 AM, Benjamin Peterson wrote:
> 2011/2/5 Christian Tismer<tismer at stackless.com>:
>> On 2/5/11 11:47 PM, Benjamin Peterson wrote:
>>> 2011/2/5 Christian Tismer<tismer at stackless.com>:
>>>> 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's not a JIT problem rather a RPython/gc one. All the RPython
>>> classes with finalizers must be known at translation time. __del__ is
>>> expensive in the for gc. To implement user level __del__, a different
>>> underlying interp class is used which has its own __del__ which the gc
>>> will call.
>> I understand. Then having a __del__ is always expensive, I guess?
>> I mean, does it involve overhead to have a __del__ at all, runtime
>> or compile time?
> It just means there's a lot of runtime bookkeeping in the GC for
> objects with __del__.
>> How feasible would it be to generate always two versions of
>> the RPython class with a stub __del__ method, which calls a
>> yet non-existing function?
>> sorry if that is non-sense, but maybe something can be done
>> to isolate these bad spots, without simply silently not calling them.
> Well, you do at least get a nice warning. I don't think this is too
> hard to work around in apps. There's also weakrefs.

Ah, we do get a warning, that is good, did not know.

Anyway, the concept of RPython is pretty old, since we needed
something that is treatable. And RPython is a good compromise
for most things.

Meanwhile, a lot of evolution has happened, most of it in the JIT
area, and maybe some things can be generated more lazily
and taken over by the JIT, since dynamic changes like the sudden
appearance of a method could probably be handled differently
than it is right now.

I will shut up, this is becoming a more general topic.

ciao - 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