On Nov 22, 5:08 am, I V <[EMAIL PROTECTED]> wrote:
> On Wed, 21 Nov 2007 17:06:15 -0800, braver wrote:
> It looks like ruby internally buffers the stream itself, which is how
> come it can support this. According to the docs:
>
> "Note that IO#eof? reads data to a input buffer."
>
> http://www.ruby-doc.org/core/classes/IO.html#M002309
>
> I'd imagine that's inefficient in a lot of cases; and I don't think it
> provides much benefit. What's the hardship in checking the return values
> of your IO calls? Or iterating over the file, which is a more elegant
> solution in many cases.
Exactly. But in many cases, built-in look-ahead is convenient. The
threads I cite in reply to Wayne are essentially trying to reimplement
the look-ahead with iterators -- and boy, it doesn't look pretty.
In many cases, you want to do this:
for line in f:
<do something with the line, setup counts and things>
if line % 1000 == 0 or f.eof(): # eof() doesn't exist in Python
yet!
<use the setup variables and things to process the chunk>
My control logic summarizes every 1000 lines of a file. I have to
issue the summary after each 1000 lines, or whatever incomplete tail
chunk remains. If I do it after the for loop, I have to refactor my
logic into a procedure to call it twice. Now I want to avoid the
overhead of the procedure call, and generally for a script to keep it
simple. (Well I guess f.eof() is an overhead itself if it's
inefficiently done in Python due to Python's impleentation of IO --
see below.) Having eof() in this case is natural, and there's no
legitimate reason for Python not to provide it -- except if its IO is
implemented so that it's hard to provide such an eof()! So in that
case, instead of ideological arguments about ways Python and not
Python, it's interesting to look at why Python implements its IO so
that giving eof() is hard, while Ruby gladly and cheerfully does it!
Cheers,
Alexy
--
http://mail.python.org/mailman/listinfo/python-list
