eof

[J. Clifford Dyer]

On Thu, Nov 22, 2007 at 07:17:41AM -0800, braver wrote regarding Re: eof:
> 
> On Nov 22, 6:08 pm, "J. Clifford Dyer" <j... at sdf.lonestar.org> wrote:
> 
> > > So why Python's IO cannot yield f.eof() as easily as Ruby's can?  :)
> 
> > Because that's not how you compare languages.  You compare languages by stating what you are actually trying to do, and figuring out the most natural solution in each language.  Not "I can do this in x--how come I can't do it in y?"
> 
> Python doesn't have f.eof() because it doesn't compare to Ruby?  Or
> because I'm trying to compare them?  :)  That's giving up to Ruby too
> early!
> 

No and no, to your two questions.  I'm not giving up on Ruby at all.  In fact, I've never tried Ruby.  My point isn't that the languages don't compare.  My point is that your question shouldn't be "why doesn't python have an eof method on its file objects?"  Your question should be "I want to do something different with the last line of a file that I iterate over.  How do I do that best in python?"  You've been given a couple solutions, and a very valid reason (performance) why buffered file objects are not the default.  You may also consider trying subclassing file with a buffered file object that provides self.eof.  (I recommend making it an attribute rather than a method.  Set it when you hit eof.)  That way you have the fast version, and the robust version.

You may find something of interest in the for/else construction as well

for line in file:
	pass
else:
    # This gets processed at the end unless you break out of the for loop.
	pass


> Ruby has iterators and generators too, but it also has my good ol'
> f.eof().  I challenge the assumption here of some majectically Python-
> wayist spirit forbidding Python to have f.eof(), while Ruby, which has
> all the same features, has it.  Saying "it's not the Python way" is
> not a valid argument.
> 

No, but showing a different python way is more valid, and if you were more forthcoming about your use case from the get-go, you would have gotten fewer vague answers.  

> The suspicion lurking in the thread above was that that has to do with
> Python IO buffering, that it somehow can't tell the f.eof() with
> automatic look-ahead/push-back/simulate read, as transparently an
> effectively as (in practice) Ruby does without much fuss.  The reason
> why such a useful feature -- useful not in Ruby or Perl or Pascal, but
> algorithmically -- is not present in Python is a recurrent mystery,
> evidenced in this group recurrently.
> 

A mystery which has been answered a couple times in this thread--it causes a performance hit, and python is designed so that you don't suffer that performance hit, unless you want it, so you have to program for it yourself.

You yourself said that performance is a complaint of yours regarding Ruby, so why claim that Ruby's way is clearly better in a case where it causes a known performance hit?

> Cheers,
> Alexy

Cheers,
Cliff