[Oren Tirosh] > I believe that when David was talking about multi-pass iterability he > wasn't referring to an iterator that can be told to "start over again" but > to an iterable object that can produce multiple independent iterators of > itself, each one good for a single iteration. To an excellent first approximation, it makes no difference. I read David the same as you, and that's where my "no such distinctions" came from. The "likewise" in "Likewise for a way to tell a multipass iterator to 'start over again'" means "and in addition to what you asked about, not that either" (which is something other people have asked about, and more often than what David asked about). > The language does make a distinction between an *iterable* object that > may have only an __iter__ method and an *iterator* that has a next > method. Sure. At the wrapper-level David works at, all Python supplies here is PyObject_GetIter(x), which returns an iterator or a NULL, and in the former case the only useful thing he can do with it is call PyIter_Next() on it. There's simply no way for him to know whether calling PyObject_GetIter(x) again will yield an iterator that produces the same sequence of values, or even whether it will yield an iterator again at all. He could hardcode knowledge about a few types, like, e.g., the builtin list type, but that wouldn't even extend to subclasses of list; similarly a subclass of file may well fiddle its iterator to be multi-pass despite that the builtin file doesn't. > ... > A Mamba programmer called Nero Hsorit has speculated in a > mamba-dev posting that in an alternative universe in a language > called 'Cobra' people kept getting confused between iterators and > iterables :-) David can't get there from here with or without confusion <wink>.
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