horpner at yahoo.com
Thu Nov 22 15:32:43 CET 2007
On 2007-11-22, braver <deliverable at gmail.com> wrote:
> On Nov 22, 10:37 am, Wayne Brehaut <wbreh... at mcsnet.ca> 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:
That person simply didn't know Python's idioms for processing
> Here folks fight the same problem in one way uglier than
> another. Iterators and whatnot are thrown at a poor li'l EOF:
> 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.
> filesize = os.stat(filename)
> 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
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.
More information about the Python-list