(A.M. Kuchling told me to post this bug report.) In section 2.3.8, "File Objects", of the Python Library Reference, the following section is given for file.next(): << In order to make a for loop the most efficient way of looping over the lines of a file (a very common operation), the next() method uses a hidden read-ahead buffer. As a consequence of using a read-ahead buffer, combining next() with other file methods (like readline()) does not work right. >> This information is necessary for anyone who mixes "for line in file:" with read()/tell()/etc. However, in the statement "for line in file:", next() is called implicitly, and therefore it may not occur to the programmer to find the information there. Therefore the documentation should be reorganized. One solution is to have the read()/tell()/etc. methods refer to the above section. i.e. "Don't use this method with next() or 'for line in file:'; see next()." A second solution is to move the above section to before the methods section (i.e. after the second paragraph after the 2.3.8 header), and to mention 'for line in file:'. i.e. "As a consequence of using a read-ahead buffer, combining next() or 'for line in file:' with other file methods (like readline()) does not work right." (Also, saying "with other file methods (like readline())" is too vague. IMHO it should specify which ones not to use. That's debatable though.)
Logged In: YES user_id=80475 IMO, the docs are fine as-is. Sometimes, trying to be over specific makes the docs less usable rather than more. The current wording pretty much covers why the iterator protocol is at odds with the readline() style methods. Of course, this could be argued to death. So, I'll leave the report open so that others can express their take.
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