proposal: another file iterator
Mon Jan 16 03:58:53 CET 2006
Jean-Paul Calderone <exarkun at divmod.com> 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
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.
More information about the Python-list