On 2007-11-22, braver <[EMAIL PROTECTED]> wrote: > On Nov 22, 10:37 am, Wayne Brehaut <[EMAIL PROTECTED]> wrote: >> As others have already pointed out, "because it's seldom >> necessary in Python". > > You know what? I've read this many times, and it's a lot of > self- congratulation. There's lot of things which can be > useful in Python.
But not all useful things should be in a library. Your use case for eof may yield to a more general solution. > This lack of EOF is inconvenient, there's nothing "Python way" > about it, as a simple search on "EOF" or "eof" in this group > demonstrates. Just a few threads: > > http://groups.google.com/group/comp.lang.python/browse_thread/thread/ed25388487b3ac7b That person simply didn't know Python's idioms for processing files. > Here folks fight the same problem in one way uglier than > another. Iterators and whatnot are thrown at a poor li'l EOF: > > http://groups.google.com/group/comp.lang.python/browse_thread/thread/b09d612e99f67561 > > The recurrence of the question simply shows Python lacks an > f.eof() method. That's all! > > Why do we may need it? The last thread shows clearly -- because the > last line processing is often a special case. After I couldn't > find the f.eof() in Python docs, I've quickly changed the logic > to this (extracts): You'll be better off with a general-purpose generator that allows special handling for the last item. http://groups.google.com/group/comp.lang.python/msg/703a513332d48dd4?dmode=source > filesize = os.stat(filename)[6] > cur_size = 0 > > def eof(): > return cur_size == filesize > > def add_line(line): > self.cur_size += len(line) > ... > if eof(): > print >>sys.stderr, "* * * eof * * *" For text mode files, the number of characters is not always equal to the file's size in bytes. > There's nothing special about Python except indentation, which > gets screwed up between editors all the time. (It's much > easier to flip- flop between TextMate and Emacs with Ruby than > with Python, without setting your tabs and spaces > pedantically.) That horse is dead, buried, decayed, and there's a fig tree growing out of the gravesight. Have a fig. > It's faster than Ruby, otherwise they're similar. When Ruby > X.Y gets faster, it'll be a tough call to between 'em. I use > Python to accomplish things I know how, with algorithms which > work and proven control logic, so this is reasonable to ask > about certain control flow equivalents. And comparisons will > always be good. :) Language comparisons are sometimes good. They are best when they are free of FUD. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
