On 12/7/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Are there any generator specific needs that are not met by the PEP 342
> implementation? Given a choice between throw(), close(), and send(), I
> would have thought that all the bases have been covered.
Agreed. When the new functionality
[Matthew F. Barnes]
> > > Perhaps it would be a useful addition to the itertools
> > > module then?
> > >
> > > itertools.interruptable(iterable)
[Raymond Hettinger]
> > Any real-world use cases or compelling contrived examples?
[Simon Wittber]
> I use something like this in the nanothr
On 12/7/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Matthew F. Barnes] Perhaps it would be a useful addition to the
> itertools
> > module then?
> >
> > itertools.interruptable(iterable)
>
> Any real-world use cases or compelling contrived examples?
I use something like this in th
[Matthew F. Barnes] Perhaps it would be a useful addition to the
itertools
> module then?
>
> itertools.interruptable(iterable)
Any real-world use cases or compelling contrived examples?
ISTM, that the code calling it.stop() would already be in position to
break-out of the iteration dir
[Tim Peters]
> ...
> For example, after
>
>def f():
>dummy = xrange(1000)
>
>f()
>
> it's not just the `dummy` list object that's reclaimed when f exits,
> it's also about 10 million integer objects.
Sorry, that example should have used "range" instead of "xrange".
Using xrang
[Weber, Gregoire]
>> We're seriously evaluating Python for use in embedded realtime systems
>> and need some informations about Pythons garbage collector.
...
[Neil Schemenauer]
> It does not run in the background. One option would be to disable
> the cyclic garbage collector and rely on the refe
Nick Coghlan wrote:
> As Fredrik pointed out a while back, the PyObject approach doesn't *have* to
> involve manual decref operations - PyObject's come with a ready made arena
> structure, in the form of PyList.
That doesn't really work: PyList_Append (which you would have to use)
duplicates th
On Tue, Dec 06, 2005 at 11:20:46AM +0100, Weber, Gregoire wrote:
> We're seriously evaluating Python for use in embedded realtime systems
> and need some informations about Pythons garbage collector.
>
> What we're interested mostly in the runtime behaviour of the GC. The
> main question is:
>
>
I just posted a lengthy message to comp.lang.python/python-list about
Python's docs; the title is "Documentation suggestions". A short
summary of the post is: "The RefGuide is hard to read and hard to keep
updated. Do we need a friendly language description? If we do that,
should the existing Re
On Tue, Dec 06, 2005 at 07:47:06AM -0800, Guido van Rossum wrote:
> Happened to see this commit. What's the magic about 10MB? Is there any
> understanding of what causes it to fail? What is the failure mode?
> Could it just be fragmentation causing the malloc or realloc to fail?
> Should we perhaps
Guido van Rossum wrote:
> Happened to see this commit. What's the magic about 10MB? Is there any
> understanding of what causes it to fail? What is the failure mode?
> Could it just be fragmentation causing the malloc or realloc to fail?
> Should we perhaps use a more conservative buffer size, e.g.
Happened to see this commit. What's the magic about 10MB? Is there any
understanding of what causes it to fail? What is the failure mode?
Could it just be fragmentation causing the malloc or realloc to fail?
Should we perhaps use a more conservative buffer size, e.g. 1MB or
even 8K (the internation
Neal Norwitz wrote:
> This is my understanding of the two approaches from what I've seen so
> far (Jeremy or Martin should correct me if I'm wrong).
>
> With current arena impl:
> * need to call PyArena_AddPyObject() for any allocated PyObject
> * need to call PyArena_AddMallocPointer() for any
13 matches
Mail list logo
