Re: [Python-Dev] Linus on garbage collection
Greg Ewing, 07.05.2011 02:26: Stefan Behnel wrote: After all, the described crash case indicates that the Document destructor was called before all of the Element destructors had been called, although all Elements reference their Document, but the Document does not refer to any of the Elements, In that case, why was the GC system regarding this as a cycle at all? There must be more going on. It's a dead-end that is referenced by a cycle, that's all. Stefan ___ 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
Re: [Python-Dev] Linus on garbage collection
Stefan Behnel wrote: It's a dead-end that is referenced by a cycle, that's all. But shouldn't it be breaking the cycle by clearing one of the objects that's actually part of the cycle, rather than part of the dead-end? I can't see how the Document could get picked for clearing unless it was actually in the cycle. Either that or I'm imagining the cyclic GC algorithm to be smarter than it actually is. -- Greg ___ 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
Re: [Python-Dev] Linus on garbage collection
On Fri, 6 May 2011 21:39:10 -0400 Glyph Lefkowitz wrote: > > The assertion that "modern hardware" is not designed for big data-structure > pointer-chasing is also a bit silly. On the contrary, modern hardware has > evolved staggeringly massive caches, specifically because large programs > (whether they're GC'd or not) tend to do lots of this kind of thing, because > there's a certain level of complexity beyond which one can no longer avoid it. "Staggeringly massive"? The average 4MB L3 cache is very small compared to the heap of non-trivial Python (or Java) workloads. And Linus is right: modern hardware is not optimized for random pointer-chasing, simply because optimizing for it is very hard. Regards Antoine. ___ 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
[Python-Dev] Python Insider translations
I wanted to take a few minutes to let you all know that the recent call for help with translating Python Insider was met with a wave of enthusiastic contributors. We now have teams prepared to translate all posts to Simplified and Traditional Chinese, German, Japanese, Portuguese, Romanian, and Spanish. Setting up each blog takes a bit of effort, so we are launching them in batches as they are ready. When all of the existing teams are launched, I will be looking for translators for additional languages. The next time you have Python related information that you would like to share with the community, I hope you will consider working with us and publishing it through Python Insider, so it can reach the widest possible audience. Either Brian Curtin or I can help you get set up, so contact one of us directly when you are ready. Thanks, Doug ___ 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
Re: [Python-Dev] Problems with regrtest and with logging
Le 06/05/2011 20:57, Vinay Sajip a écrit : Éric Araujo netwok.org> writes: Second: in packaging, we have two modules that create a logging handler. I’m not sure how if we should change the code or fix the tests to restore the _handlerList, or how. If you are saying this happens in your unit tests for packaging, then you can either restore the _handlerList using the approach in test_logging, or else you can just close the handlers when you've done with them. We create one handler in a command-line script, not in the lib, which is the Right Way AFAIU, but there is also one module that creates one handler (in order to set its level depending on a verbose attribute) deep in the library code, not in the command-line script, which I think is bad. Our tests that instantiate that object (dist.Distribution) end up modifying logging._handlerList, but I feel that the code is wrong, not the tests. The code is on https://bitbucket.org/tarek/cpython, in Lib/packaging. Thanks! ___ 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
Re: [Python-Dev] Problems with regrtest and with logging
Hi, Le 06/05/2011 22:07, R. David Murray a écrit : On Fri, 06 May 2011 19:51:31 +0200, =?UTF-8?Q?=C3=89ric_Araujo?= wrote: regrtest helpfully reports when a test leaves the environment unclean (sys.path, os.environ, logging._handlerList), but I think the implementation is buggy: it compares object identity and then value. Why is comparing identity useful? I’d just use ==. It makes writing cleanup code easier (just use addCleanup(setattr, obj, 'attr', copy(obj.attr))). Well, the implementation is intentional. Nick (I think) added the identity check, and he had a reason at the time. I don't remember what it was, though. Drat. Nick, if it was indeed you, can you enlighten me? /off to replace all those addCleanup/setattr combos :( Regards ___ 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
Re: [Python-Dev] Linus on garbage collection
On 2011-05-07, at 03:39 , Glyph Lefkowitz wrote: > > I don't know if there's a programming language and runtime with a real-time, > VM-cooperating garbage collector that actually exists today which has all the > bells and whistles required to implement an OS kernel, so I wouldn't give the > Linux kernel folks too much of a hard time for still using C; but there's > nothing wrong with the idea in the abstract. Not sure it had all those bells and whistles, and there were other issues, but I believe Lisp Machines implemented garbage collection at the hardware (or at least microcode) level, and the OS itself provided a pretty direct interface to it (it was part of the core services). ___ 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
Re: [Python-Dev] cpython (2.7): Some tests were incorrectly marked as C specific.
On Sat, 07 May 2011 23:16:51 +0200 raymond.hettinger wrote: > > +class TestErrorHandling_Python(unittest.TestCase): > +module = py_heapq This class contains no tests. Regards Antoine. ___ 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
