On Fri, 12 Jul 2002, Guido van Rossum wrote:
I don't see what's wrong with the file object. Iterating over a file changes the file's state, that's just a fact of life.
That's exactly the point. Iterators and containers are different. Walking over a container shouldn't mutate it, whereas an iterator has mutable state independent of the container.
The key problem is that the file's __iter__ method returns something whose state depends on the file, thus breaking this expectation. Either __iter__ should be implemented to fulfill its commitment, or there shouldn't be an __iter__ method on files at all.
Iterators don't have to have an undelying container! (E.g. generators.)
I'm not suggesting that the semantics of files themselves are "broken" or have a "wart" that needs to be fixed -- merely that we should decide on a place for files to live in our world of containers and iterators, so we can set and maintain consistent expectations.
What are your expectations? I think that both file.__iter__() returning file (as it does with Oren's patch) or file.__iter__() returning an xreadlines object (as it still does in CVS) are fine as far as reasonable expectations for iterators go.
--Guido van Rossum (home page: http://www.python.org/~guido/)