Adam DePrince adam at cognitcorp.com
Mon Dec 20 06:44:44 CET 2004

On Sun, 2004-12-19 at 23:43, Jp Calderone wrote:
> On Sun, 19 Dec 2004 23:12:27 -0500, Adam DePrince <adam at cognitcorp.com> wrote:
> > [snip]
 to free the memory, of course.
>     The support of iterators is a cool idea, but I'm not sure
> it is actually useful.  Consider the case where not all bytes 
> are written.  How is an application supposed to handle writing 
> the rest of the bytes, if they have been consumed from an 
> iterator?  Hopefully I'm missing the obvious answer, because
> supporting arbitrary iterators would be cool, but it seems like
> only sequences can really be usefully supported.

I see, you are thinking about non-blocking I/O.  Perhaps, instead of
returning the byte count, I could return a tuple containing the byte
count and a new iterator that contains the unconsumed data.   This would
be a good reason to not use ALLOCA, for the new iterator could be a
chain of something to iterate over what is left of the old data
structure and the previously used iterator.  If only iterators had a
"push" method.

So, my changes for tomorrow morning will be:

* Smarter non-blocking I/O behaivor (generate an iterator as described
* Better memory allocation (no alloca) 
* No silent failures.

- Adam

>     I agree it's a bit small for a PEP.  I think a patch,
> including documentation and unit tests (something along the 
> lines of http://cvs.twistedmatrix.com/cvs/*checkout*/trunk/sandbox/exarkun/test_iovec.py?content-type=text%2Fplain&rev=9505&root=Twisted
> for example) on sf.net is probably a good next step.  I imagine 
> there will be some resistence to adding this for 2.4.1, though,
> meaning it may have to wait for 2.5.

I'm patient.  

>   Jp
Adam DePrince 

More information about the Python-list mailing list