Lazy "for line in f" ?

[Alexandre Ferrieux]

On Jul 22, 7:21 pm, Miles <semantic... at gmail.com> wrote:
> On 7/22/07, Alexandre Ferrieux <alexandre.ferrieux at gmail dot com> wrote:
>
> > The Tutorial says about the "for line in f" idiom that it is "space-
> > efficient".
> > Short of further explanation, I interpret this as "doesn't read the
> > whole file before spitting out lines".
> > In other words, I would say "lazy". Which would be a Good Thing, a
> > much nicer idiom than the usual while loop calling readline()...
>
> > But when I use it on the standard input, be it the tty or a pipe, it
> > seems to wait for EOF before yielding the first line.
>
> It doesn't read the entire file, but it does use internal buffering
> for performance.  On my system, it waits until it gets about 8K of
> input before it yields anything.  If you need each line as it's
> entered at a terminal, you're back to the while/readline (or
> raw_input) loop.

How frustrating ! Such a nice syntax for such a crippled semantics...

Of course, I guess it is trivial to write another iterator doing
exactly what I want.
But nonetheless, it is disappointing not to have it with the standard
file handles.
And speaking about optimization, I doubt blocking on a full buffer
gains much.
For decades, libc's fgets() has been doing it properly (block-
buffering when data come swiftly, but yielding lines as soon as they
are complete)... Why is the Python library doing this ?

-Alex