On Wed, 18 Feb 2009 at 21:25, Antoine Pitrou wrote: > Nick Coghlan <ncoghlan <at> gmail.com> writes: >> >> I *think* the 2.x system had an internal buffer that was used by the >> file iterator, but not by the file methods. With the new IO stack for >> 3.0, there is now a common buffer shared by all the file operations >> (including iteration). >> >> However, given that the lifting of the restriction is currently >> undocumented, I wouldn't want to see a commitment to keeping it lifted >> until we know that it won't cause any problems for the io-in-c rewrite >> for 3.1 (hopefully someone with more direct involvement with that >> rewrite will chime in, since they'll know a lot more about it than I do). > > As you said, there is no special buffering for the file iterator in 3.x, which > means the restriction could be lifted (actually there is nothing relying on this > restriction in the current code, except perhaps the "telling" flag in > TextIOWrapper). Currently I have python (2.x) code that uses 'readline' instead of 'for x in myfile' in order to avoid the 'for' buffering (ie: be presented with the next line as soon as it is written to the other end of a pipe, instead of waiting for the buffer to fill). Does "no special buffering" mean that 'for' doesn't use a read-ahead buffer in p3k, or that readline does use such a buffer, because the latter could make my code break unexpectedly when porting to p3k. --RDM
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