Re: [Python-Dev] Python 3.0 urllib fails with chunked HTTP responses

The inheritance from io.RawIOBase seems fine. --Guido van Rossum (home page: http://www.python.org/~guido/) On Mon, Dec 15, 2008 at 11:19 AM, Jeremy Hylton wrote: > I have a patch that appears to fix this bug > http://bugs.python.org/file12361/urllib-chunked.diff > but I'm not sure about its i

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

On Tue, Dec 16, 2008 at 8:00 PM, Antoine Pitrou wrote: > 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? > >

[Python-Dev] Please test OSX installer

I just created an OSX installer for 2.5.3c1. As it's the first time I do that, I'd appreciate if somebody could test it and report whether it works (as well as the 2.5.2 one did). http://www.python.org/download/releases/2.5.3/ Regards, Martin ___ Python

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

Antoine Pitrou pitrou.net> writes: > > We could let the user configure the threshold between the old policy and the new > policy. Currently it is hard-wired to a value of 1 (that is, 1 > long-lived objects tracked by the GC). I've removed the threshold in the latest patches because it d

Re: [Python-Dev] Please test OSX installer

Worked flawlessly both on an x86 MacBook Pro running Leopard (10.5) and a ppc PowerBook G4 running Tiget (10.4). The only issue is that the Python logo makes the text in the sidebar of the installer hard to read. I didn't test the GUI app. Thanks for doing this! --Guido van Rossum (home page: h

Re: [Python-Dev] Please test OSX installer

I've installed it on a MacBook Air running Leopard (10.5.6). Installer ran like a charm, but when I ran the following in IDLE: >>> from test.regrtest import main >>> main() I got a "Problem Report for Python" pop-up. Skip to "///" for "Problem Details". Interestingly, the test completed with th

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

Nick Coghlan wrote: Actually, I believe 3.0 already took a big step towards allowing this by changing the way modules are initialised. It's a step, but I wouldn't call it a big one. There are many other problems to be solved before fully independent interpreters are possible. -- Greg

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

> I've removed the threshold in the latest patches because it didn't make much > sense when a few long-lived objects contained a lot of objects not tracked by > the GC. > > Another improvement I've included in the latest patches (but which is > orthogonal to the algorithmic change) is that simple

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

Martin v. Löwis v.loewis.de> writes: > > So despite the organizational overhead, I'd appreciate if you could > create separate patches, if not separate issues. Ok, I'm gonna do that. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.or

[Python-Dev] Atomic instructions for reference count increment/decrement

Hi all, I'm new here, so bear with me. I tried googling this, but the closest I came up with was a post from 2000. >From the discussion about getting rid of the GIL lately, what I read from it is that reference counting is the main obstacle. My question is, why aren't hardware supported atomic in

Re: [Python-Dev] Atomic instructions for reference count increment/decrement

On Wed, Dec 17, 2008 at 7:33 PM, Arnar Birgisson wrote: > >From the discussion about getting rid of the GIL lately, what I read > from it is that reference counting is the main obstacle. My question > is, why aren't hardware supported atomic increments and decrements > being used for the referenc