Taking the route of least evasiveness, I have come up with
a VERY simple iterator interface for fileinput.

Basically, __iter__() returns self and next() calls
__getitem__() with the proper number.  This was done to
have the patch only add methods and not change any
existing ones, thus minimizing any chance of breaking
existing code.

Now the module on the whole, however, could possibly
stand an update now that generators are coming.  I have
a recipe up at the Cookbook that uses generators to
implement fileinput w/o in-place editing
(http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/112506).
 If there is enough interest, I would be quite willing
to rewrite fileinput using generators.  And if some of
the unneeded methods could be deprecated (__getitem__,
readline), then the whole module could probably be
cleaned up a decent amount and have a possible speed
improvement.

Logged In: YES 
user_id=35752

Why do you need fileinput to have a __iter__ method?  As
far as I can see it only slows things down.  As it is now
iter(fileinput.input()) works just fine.  Adding __iter__
and next() just add another layer of method calls.

Logged In: YES 
user_id=357491

Adding an iterator interface that returns itself means that
you only need to keep track of a single object.  Using the
iter() fxn on the original fileinput returns a canned
iterator that has none of the methods that a FileInput
instance has.

This means that if you want to stop iterating over the
current file and move on to the next one in the FileInput
instance, you have to call .nextfile() on the original
object; you can't call it on the iterator.

Having the __iter__() method return the instance itself
means that you can call .nextfile() on the iterator (or the
original since they are the same).  It also also updates the
module (albeit in a hackish way) to be a little bit more modern.

Also note that I uploaded a new diff and deleted the old
one; I accidently left out the return command in the
original diff.

Logged In: YES 
user_id=35752

I'm still not getting it.  It only way to get an 'iterator'
object wrapping the FileInput instance is to call iter() on
it.  Why would you want to do that?  Just use readline() and
nextfile().

Logged In: YES 
user_id=357491

The point of the patch was to put an iterator interface on
to fileinput without requiring a wrapper.  Basically it was
to update it so that it if for some reason for loops start
to require an iterator interface then it is already done. 
It was also to make sure that if an iterator was needed that
it would have all the methods it could need.

A side-effect is the need for one less object if you want an
iterator since __iter__ just returns self.  One possible
desire of this is passing around the instance.  If you pass
the iterator as fileinput is now implemented you don't have
the access to the original instance and thus can't use any
of its methods.  If you pass the FileInput instance you
would have to regenerate the iterator everytime you wanted
to use it after being passed.

With this implementation you just pass the original instance
since it can act as a FileInput instance or an iterator.

I realize this is not down-right needed, I am not arguing
there.  I am just saying that it is a nice feature to have
that does not add any excessive feature to the language.

Logged In: YES 
user_id=35752

I've checked in a modified version of this patch.  Instead
of FileInput.next calling FileInput.__getitem__ I've made
__getitem__ call next.  This keeps the common case of
"for line in fileinput.input()" fast.

See fileinput 1.9.