On Sun, 02 Nov 2008 10:21:26 +1000, Nick Coghlan wrote: > 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).
Though there is a fair difference from "explicitly documented as implementation details" and the real-world code where programmers have learnt to save code lines by relying on the reference-counting semantics. [[ my 0.2: it would be a great loss if we lose reference-counting semantic (eg: objects deallocated as soon as they exit the scope). I would bargain that for a noticable speed increase of course, but my own experience with standard GCs from other languages has been less than stellar. ]] -- Giovanni Bajo Develer S.r.l. http://www.develer.com _______________________________________________ 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
