Maciej Fijalkowski wrote: >> ... > >> 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.
Yep, I'm pretty those are all even explicitly documented as implementation details of CPython (PEP 343's with statement was largely added as a cross-implementation way of guaranteeing prompt cleanup of resources like file handles without relying on CPython's __del__ semantics or writing your own try/finally statements everywhere). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --------------------------------------------------------------- _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
