> 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. [Ping] > 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. What commitment? 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4