On Wednesday 17 July 2002 06:40 pm, Guido van Rossum wrote: ... > > The file object, unless you make it into an iterator, is not "a > > container" like all others and just sits there -- a bit of a wart. > > I must be misunderstanding. How does making the file object into an > iterator make it a container??? My fault for unclear expression! I mean: if it's an iterator, it's an iterator. All OTHER iterables (iterables that aren't iterators) are (what some call) containers. It's not QUITE that way, but Python would be easier to teach if it were. > > to Oren but he disliked it (because it meant readline would not > > respect its numeric argument, if any, in that case). > > Hm, you should've sent it to me. The numeric argument was a mistake I > think. Who ever uses it? Not me, and I think it's advisory anyway according to the docs. Still, it doesn't solve the reference-loop-between-two-deuced-things- that-don't-cooperate-with-gc problem. And I can't see how either could be made into a WEAK reference given that xreadlines objects in other contexts need to hold a strong ref to the file they work on -- we'd have to refactor xreadlines objects too, a core part holding a weak ref and a shell around it (holding a strong ref to the file) to support ordinary calls to xreadlines.xreadlines. Messy:-(. Alex
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