On Jul 22, 7:21 pm, Miles <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
