[Python-Dev] [ANN] EuroPython 2009 – Call for Participation!

On behalf of the EuroPython 2009 organisation it is my privilege and honour to announce the 'Call for Participation' for EuroPython 2009! EuroPython is the conference for the communities around Python, including the Django, Zope and Plone communities. This years conference will be held in Birming

Re: [Python-Dev] Calling the GC less often when there are lots of long-lived objects

Christian Heimes cheimes.de> writes: > > Is it reasonable to implement multiple policies so the user can switch > between them? Or is the new algorithm superior in all cases? We could let the user configure the threshold between the old policy and the new policy. Currently it is hard-wired to a

Re: [Python-Dev] Calling the GC less often when there are lots of long-lived objects

Antoine Pitrou schrieb: > Is anybody opposed to the principle of this proposal? Is it reasonable to implement multiple policies so the user can switch between them? Or is the new algorithm superior in all cases? ___ Python-Dev mailing list Python-Dev@pyt

Re: [Python-Dev] Calling the GC less often when there are lots of long-lived objects

Antoine Pitrou wrote: I've proposed a patch which basically implements Martin's suggestion in http://mail.python.org/pipermail/python-dev/2008-June/080579.html Is anybody opposed to the principle of this proposal? Sounds okay to me. -- Greg ___ Pyth

[Python-Dev] Calling the GC less often when there are lots of long-lived objects

Hello, There are recurring complaints about the garbage collector degrading performance when lots of objects are created in a row. In issue #4074, I've proposed a patch which basically implements Martin's suggestion in http://mail.python.org/pipermail/python-dev/2008-June/080579.html to base the

Re: [Python-Dev] The endless GIL debate: why not remove thread support instead?

On Dec 13, 2008, at 5:47 PM, Martin v. Löwis wrote: They were originally invented in 1965, on Multics (1970) they were used to perform compilation in the background. When Unix came along, it *added* address space separation, introducing what is now known as processes. Yes, and a lot of th

Re: [Python-Dev] Trap SIGSEGV and SIGFPE

On Dec 11, 2008, at 3:05 PM, Martin v. Löwis wrote: If it is actually possible to print a stack trace, that could be useful indeed. I'm then skeptical that this is possible in the general case (i.e. displaying the full C stack), but displaying (parts of) the Python stack might be possible. I

Re: [Python-Dev] Reindenting the C code base?

On Sat, Dec 13, 2008 at 11:26 PM, Guido van Rossum wrote: > > I think we should not do this. We should use 4 space indents for new > files, but existing files should not be reindented. If you reindent, > much of the history of the file is essentially lost -- "svn blame" > will blame whoever reinde

Re: [Python-Dev] Reindenting the C code base?

On Sat, 13 Dec 2008, Guido van Rossum wrote: If you reindent, much of the history of the file is essentially lost -- "svn blame" will blame whoever reindented the code, and it's a pain to go back. I am not a subversion specialist, but it appears this part can be handled gracefully by passing

Re: [Python-Dev] Reindenting the C code base?

On Mon, Dec 15, 2008 at 11:21 AM, Brett Cannon wrote: > On Mon, Dec 15, 2008 at 00:20, Georg Brandl wrote: > > Jeffrey Yasskin schrieb: > >> On Sun, Dec 14, 2008 at 8:26 AM, Guido van Rossum > wrote: > >>> On Sat, Dec 13, 2008 at 2:11 PM, Antoine Pitrou > wrote: > Guido van Rossum python