> I redid my tests by calling GC.Collect() afterwards, and the "normal" > case works just fine, but not the attached case. So yes, they do work. > :) Yes, of course an equivalent step is necessary in Jython too. test_finalizers.py cares for this via the gc module, which should be the right implementation-independent way. (Hope the waittime of 0.1s is sufficient for the asynchronous gc in practice)
> But then the end user has to know to run __ensure_finalizer__() on > each instance, correct? Yes, correct. Sure, this is not nice, but technically I see no better way with reasonable costs. On the other hand I thought - better provide this manual way to fix it than completely ignore the issue. (__ensure_finalizer__ was -anyway- only a byproduct of implementing finalizer support for new-style classes) > Keeping a set of weak references would solve the problem at a > not-too-horrible cost (which I think is what PyPy does, but they can > share it with the GC so it's not really overhead). Is this regarding to acquired finalizers or gc statistics? Case acquired finalizers: There was a discussion in the Jython bugtracker with the clear result that instances of a class won't be tracked. Too many additional references, too expensive, not worth the cost. Case GC statistics: Since it is for debugging, I think it would be okay if one could explicitly tell the gc module which objects to monitor, or maybe make monitoring optional by a start up flag. In both cases - indeed - a set of weak references as you suggested would be the way. > Honestly though, why in the heck would anyone even want to do this? Is > there a use case, or is it just matching compatibility with CPython? Case GC statistics: Debugging like Markus pointed out. Actually test_gc.py completely relies on it and would currently not pass on Jython or IronPython, although both support gc in fact. (I am currently reasoning how to improve this, because I will need gc test tools for JyNI.) Case acquired finalizers: Yes, indeed I don't know. But I still think, "why would anyone want this?" frequently caused subtle bugs, wrong optimizations, several regressions and lots of spam on stack overflow during the history of software design. So, for me "matching compatibility with CPython" is a fair enough reason to take the issue serious - at least when I work on related stuff anyway. Honestly, the right solution would be that CPython would disallow acquired finalizers, if nobody needs this anyway. Maybe I will try to turn this into a PEP one day - since they already disallowed repeated finalization/resurrection, it might be not too utopian. However I would need more information on the issue throughout the Python eco system (which is why I bother you :-) ) - Stefan _______________________________________________ Ironpython-users mailing list Ironpython-users@python.org https://mail.python.org/mailman/listinfo/ironpython-users
