proposal: another file iterator

Paul Rubin http
Mon Jan 16 03:58:53 CET 2006

Jean-Paul Calderone <exarkun at> 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('',, 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(, '', (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, 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 mailing list