Jean-Paul Calderone <[EMAIL PROTECTED]> writes: > Which is only very slightly longer than your version. I would like > it even more if iter() had been written with the impending doom of > lambda in mind, so that this would work: > > for chunk in iter('', f.read, blocksize): > ... > > But it's a bit late now.
Well, iter could be extended to take *args and **kwargs parameters, so you'd say for chunk in iter(f.read, '', (blocksize,)): ... That leaves the params in a clumsy order for backwards compatibility, but it's not unbearable. > Anyhow, here are some questions about your iterbytes(): > > * Would it guarantee the chunks returned were read using a single > read? If blocksize were a multiple of the filesystem block size, > would it guarantee reads on block-boundaries (where possible)? I expect that the iterator's .next() would just get the result of f.read(blocksize), which makes no such guarantees. > * How would it handle EOF? Would it stop iterating immediately >after the first short read or would it wait for an empty return? Wait for empty return. > * What would the buffering behavior be? Could one interleave > calls to .next() on whatever iterbytes() returns with calls to > .read() on the file? I don't see why not. Iterbytes would just call read() and yield the result. You could even have multiple iterators going at once. -- http://mail.python.org/mailman/listinfo/python-list