Steven Bethard <[EMAIL PROTECTED]> wrote: ... > Beware of mixing iterator methods and readline:
_mixing_, yes. But -- starting the iteration after some other kind of reading (readline, or read(N), etc) -- is OK... > http://docs.python.org/lib/bltin-file-objects.html > > 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. > > I haven't tested your code in particular, but this warning was enough to > make me generally avoid mixing iter methods and other methods. Yeah, I know... it's hard to explain exactly what IS a problem and what isn't -- not to mention that this IS to some extent a matter of the file object's implementation and the docs can't/don't want to constrain the implementer's future freedom, should it turn out to matter. Sigh. In the Nutshell (2nd ed), which is not normative and thus gives me a tad more freedom, I have tried to be a tiny bit more specific, taking advantage, also, of the fact that I'm now addressing the 2.3 and 2.4 implementations, only. Quoting from my current draft (pardon the XML markup...): """ interrupting such a loop prematurely (e.g., with <c>break</c>), or calling <r>f</r><c>.next()</c> instead of <r>f</r><c>.readline()</c>, leaves the file's current position at an arbitrary value. If you want to switch from using <r>f</r> as an iterator to calling other reading methods on <r>f</r>, be sure to set the file's current position to a known value by appropriately calling <r>f</r><c>.seek</c>. """ I hope this concisely indicates that the problem (in today's current implementations) is only with switching FROM iteration TO other approaches to reading, and (if the file is seekable) there's nothing so problematic here that a good old 'seek' won't cure... Alex -- http://mail.python.org/mailman/listinfo/python-list
