> > No. I won't have "for line in file" be slower than attainable. > > +1. I _intensely_ want to be able to teach beginners to use "for line in > file" and have it be fast in the common case. "Nice" behavior for rarer > cases of prematurely interrupted loops is OK, if feasible, but secondary. > Having "for line in file" play nicely with other method calls on 'file' has > no importance to me in this context -- no more than, e.g., having "for item > in alist" play nicely with calls to mutating methods of object alist. Exactly. > > The only solution I accept is a complete rewrite of the I/O system > > without using stdio, so xreadlines can be integrated. > > I thought Just's suggestion (about having the file object remember > the xreadlines object in use, so that another for loop would continue > right where the first one exited) seemed like a reasonable hack -- a > compromise of reasonably little effort for some small secondary gain. Oops, I missed that. That seems reasonable indeed. > Guess I must be missing something? Of course the "complete rewrite" > is an alluring prospect -- for many other reasons, such as enabling > user control of file buffering in cross-platform ways, *yum* -- but it's not > going to happen in time for 2.3 anyway, is it? I'm not going to hold up the 2.3 release, but if a patch lands in the SF patch manager, I'm not going to reject it. Hint, hint. :-) --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