[pypy-dev] Compat. in 1.4.1 __del__

[Christian Tismer]

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?

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.

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