2011/2/5 Christian Tismer <tis...@stackless.com>: > 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?
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 _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
