[pypy-dev] Compat. in 1.4.1 __del__

[Benjamin Peterson]

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.

>
> cheers - chris



-- 
Regards,
Benjamin