PEP 234 little bug?

[Hans Nowak]

Just van Rossum wrote:
> 
> In article <3C817FC1.A155DBAB at earthlink.net>,
>  Hans Nowak <wurmy at earthlink.net> wrote:
> 
> > Michael 'Mickey' Lauer wrote:
> > >
> > > Just read through some of the already implemented PEPs.
> > >
> > > PEP 234 (iterators) states:
> > >
> > > >    - It has been proposed that a file object should be its own
> > > >      iterator, with a next() method returning the next line.  This
> > > >      has certain advantages, and makes it even clearer that this
> > > >      iterator is destructive.  The disadvantage is that this would
> > > >      make it even more painful to implement the "sticky
> > > >      StopIteration" feature proposed in the previous bullet.
> > > >
> > > >      Resolution: this has been implemented.
> > >
> > > I can't see a next() in a file object. Shouldn't it be
> > > "Resolution: this has not been implemented." ?
> >
> > Hm, I don't think so. I think it does not say that the *file*
> > object should have a next() method... rather, it says that
> > it's its own iterator, and the iterator has the next()
> > method. Maybe the wording could have been a bit more careful,
> > but essentially it's true what is says. And iterating over
> > files has indeed been implemented in 2.2.
> 
> Just yesterday I've filed a bug about the current behavior that is
> caused by the fact that the file object is *not* its own iterator:

Should it be? This may be a dumb question, but are there important
reasons to do this, besides conformance with the PEP? I mean, the
current situation does do the job; "for line in file" works. What
would be the additional benefit of making a file its own
iterator?

-- 
Hans (base64.decodestring('d3VybXlAZWFydGhsaW5rLm5ldA==')) 
# decode for email address ;-)
The Pythonic Quarter:: http://www.awaretek.com/nowak/