> ... > > We know it is the plan for PyPy to work in this way, and also that > Jython and Ironpython works like that (using the host vm's GC), so it > seems to be somehow agreeable with the python semantics (perhaps not > really with __del__ but they are not really nice anyway). > PyPy has a semi-advanced generational moving gc these days. It's not as well tuned as JVMs one, but it works quite well. Regarding semantic changes, there is a couple which as far as I remember are details which you should not rely on anyway (At least some of the below applies also for Jython/IronPython): * __del__ methods are not called immediately when object is not in a cycle * all objects are collected, which means objects in cycles are broken in arbitrary order (gc.garbage is always empty), but normal ordering is preserved. * id's don't always resemble address of object in memory * resurrected objects have __del__ called only once in total. I think for example last one is so obscure detail that if someone relies on it it's his problem :) Cheers, fijal
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4