> > Can you remind me of your definition of "iterable"? Mine is > > "something for which iter() works", which clearly isn't yours. :-) > > Right -- I mean something closer to what I've seen others call > "a container". By your definition, iterators are indeed iterable. > I would love for all iterables-by-your-definition to divide neatly > into iterators and what-many-call-containers. > > 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??? > > > f.seek does cooperate with f.next now, doesn't it? since it > > > invalidates f's xreadlines object, if any? > > > > Not yet. You may have seen Oren's patch for this. Unfortunately it > > Right -- that's what I had in mind. I had also tweaked it so that > readline sort of interoperated with it (delegating to next if the file > object is holding an xreadlines object) and sent the modified patch > 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? --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