> > Maybe the xreadlines object could grow a flush() method that throws > > away its buffer, and f.seek() could call that if there's a cached > > xreadlines iterator? > > Couldn't f.seek just decref the xreadlines object and put a NULL > into f's pointer to the xreadlines object? Well, that wouldn't help for code that's hanging on to the iterator. I also just realized that having the file object point to the xreadlines object creates a cycle, since the xreadlines object already points to the file. And neither participates in GC. I guess the xreadlines object could drop the pointer to the file once it's raised StopIteration, as a way to ensure that this is a sink state. Or we could add GC support to file objects and xreadline objects (sigh). --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