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
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.
> 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.
More information about the Python-list