summaryrefslogtreecommitdiffstats
path: root/Lib
diff options
context:
space:
mode:
authorGuido van Rossum <guido@python.org>2002-08-06 15:55:28 (GMT)
committerGuido van Rossum <guido@python.org>2002-08-06 15:55:28 (GMT)
commit7a6e95948cd2e163c066943f755d85007c306047 (patch)
tree328dc229ed79fc399d99ff2b7e34a50d68b7ae9c /Lib
parent3a451b1d1951b6f48c553e4cbc4b35ef4933cd2a (diff)
downloadcpython-7a6e95948cd2e163c066943f755d85007c306047.zip
cpython-7a6e95948cd2e163c066943f755d85007c306047.tar.gz
cpython-7a6e95948cd2e163c066943f755d85007c306047.tar.bz2
SF patch 580331 by Oren Tirosh: make file objects their own iterator.
For a file f, iter(f) now returns f (unless f is closed), and f.next() is similar to f.readline() when EOF is not reached; however, f.next() uses a readahead buffer that messes up the file position, so mixing f.next() and f.readline() (or other methods) doesn't work right. Calling f.seek() drops the readahead buffer, but other operations don't. The real purpose of this change is to reduce the confusion between objects and their iterators. By making a file its own iterator, it's made clearer that using the iterator modifies the file object's state (in particular the current position). A nice side effect is that this speeds up "for line in f:" by not having to use the xreadlines module. The f.xreadlines() method is still supported for backwards compatibility, though it is the same as iter(f) now. (I made some cosmetic changes to Oren's code, and added a test for "file closed" to file_iternext() and file_iter().)
Diffstat (limited to 'Lib')
0 files changed, 0 insertions, 0 deletions