eof

[Neil Cerutti]

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:
>
> 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