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
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
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 problem.
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
instance of
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
have.
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 right at
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.next()
gives
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 seem
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 StopIteration, but
s =
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)
But
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 = StringIO.StringIO(foo)
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
12 matches
Mail list logo
