Re: [Python-Dev] Problems with the Python Memory Manager

2005-11-17 Thread Fredrik Lundh
Travis Oliphant wrote: > Bingo. Yes, definitely allocating new _types_ (an awful lot of them...) > --- that's what the "array scalars" are: new types created in C. are you allocating PyTypeObject structures dynamically? why are you creating an awful lot of new type objects to represent the cont

Re: [Python-Dev] Problems with the Python Memory Manager

2005-11-17 Thread Fredrik Lundh
Travis Oliphant wrote: > The fact that it did happen is what I'm reporting on. If nothing will > be done about it (which I can understand), at least this thread might > help somebody else in a similar situation track down why their Python > process consumes all of their memory even though their o

Re: [Python-Dev] Problems with the Python Memory Manager

2005-11-17 Thread Michael Hudson
Travis Oliphant <[EMAIL PROTECTED]> writes: > Bingo. Yes, definitely allocating new _types_ (an awful lot of them...) > --- that's what the "array scalars" are: new types created in C. Ah! And, er, why? > If they don't get properly collected then that would definitely have > created the probl

Re: [Python-Dev] Problems with the Python Memory Manager

2005-11-17 Thread Travis Oliphant
>> >> Bingo. Yes, definitely allocating new _types_ (an awful lot of >> them...) >> --- that's what the "array scalars" are: new types created in C. > > > Do you really mean that someArray[1] will create a new type to represent > the second element of someArray? I would guess that you create an

[Python-Dev] Iterating a closed StringIO

2005-11-17 Thread Walter Dörwald
Currently StringIO.StringIO and cStringIO.StringIO behave differently when iterating a closed stream: s = StringIO.StringIO("foo") s.close() s.next() gives StopIteration, but s = cStringIO.StringIO("foo") s.close() s.next() gives "ValueError: I/O operation on closed file". Should they raise t

Re: [Python-Dev] Memory management in the AST parser & compiler

2005-11-17 Thread Brett Cannon
On 11/16/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Thomas Lee wrote: > > > Even if it meant we had just one function call - one, safe function call > > that deallocated all the memory allocated within a function - that we > > had to put before each and every return, that's better than what we

Re: [Python-Dev] Memory management in the AST parser & compiler

2005-11-17 Thread Brett Cannon
On 11/16/05, Thomas Lee <[EMAIL PROTECTED]> wrote: > Just messing around with some ideas. I was trying to avoid the ugly > macros (note my earlier whinge about a learning curve) but they're the > cleanest way I could think of to get around the problem without > resorting to a mass deallocation righ

Re: [Python-Dev] Iterating a closed StringIO

2005-11-17 Thread Guido van Rossum
On 11/17/05, Walter Dörwald <[EMAIL PROTECTED]> wrote: > Currently StringIO.StringIO and cStringIO.StringIO behave differently > when iterating a closed stream: > > s = StringIO.StringIO("foo") > s.close() > s.next() > > gives StopIteration, but > > s = cStringIO.StringIO("foo") > s.close() > s.nex

Re: [Python-Dev] Memory management in the AST parser & compiler

2005-11-17 Thread Alex Martelli
On Nov 17, 2005, at 12:46 PM, Brett Cannon wrote: ... >> alloca? >> >> (duck) >> > > But how widespread is its support (e.g., does Windows have it)? Yep, spelled with a leading underscore: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ vclib/html/_crt__alloca.asp Alex _

Re: [Python-Dev] Coroutines (PEP 342)

2005-11-17 Thread Martin Blais
On 11/14/05, Bruce Eckel <[EMAIL PROTECTED]> wrote: > I just finished reading PEP 342, and it appears to follow Hoare's > Communicating Sequential Processes (CSP) where a process is a > coroutine, and the communicaion is via yield and send(). It seems that > if you follow that form (and you don't s

Re: [Python-Dev] Iterating a closed StringIO

2005-11-17 Thread Walter Dörwald
Am 17.11.2005 um 22:03 schrieb Guido van Rossum: > On 11/17/05, Walter Dörwald <[EMAIL PROTECTED]> wrote: >> Currently StringIO.StringIO and cStringIO.StringIO behave differently >> when iterating a closed stream: >> >> s = StringIO.StringIO("foo") >> s.close() >> s.next() >> >> gives StopIteratio

Re: [Python-Dev] Memory management in the AST parser & compiler

2005-11-17 Thread Thomas Lee
Portability may also be an issue to take into consideration: http://www.eskimo.com/~scs/C-faq/q7.32.html http://archives.neohapsis.com/archives/postfix/2001-05/1305.html Cheers, Tom Alex Martelli wrote: >On Nov 17, 2005, at 12:46 PM, Brett Cannon wrote: >... > > >>>alloca? >>> >>>(duck) >

Re: [Python-Dev] Iterating a closed StringIO

2005-11-17 Thread Guido van Rossum
On 11/17/05, Walter Dörwald <[EMAIL PROTECTED]> wrote: > Am 17.11.2005 um 22:03 schrieb Guido van Rossum: > > > On 11/17/05, Walter Dörwald <[EMAIL PROTECTED]> wrote: > >> Currently StringIO.StringIO and cStringIO.StringIO behave differently > >> when iterating a closed stream: > >> > >> s = String

Re: [Python-Dev] Memory management in the AST parser & compiler

2005-11-17 Thread Alex Martelli
On Nov 17, 2005, at 5:00 PM, Thomas Lee wrote: > Portability may also be an issue to take into consideration: Of course -- but so is anno domini... the eskimo.com FAQ is (C) 1995, and the neohapsis.com page just points to the eskimo.com one: > http://www.eskimo.com/~scs/C-faq/q7.32.html > htt