On Sun, 2004-12-19 at 23:43, Jp Calderone wrote: > On Sun, 19 Dec 2004 23:12:27 -0500, Adam DePrince <[EMAIL PROTECTED]> wrote: > > [snip] [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 above) * 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 -- http://mail.python.org/mailman/listinfo/python-list