On 2/5/11 11:47 PM, Benjamin Peterson wrote: > 2011/2/5 Christian Tismer<tis...@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:tis...@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/ _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
