proposal: another file iterator

[Paul Rubin]

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
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.