On Oct 1, 10:46 am, Luis Zarrabeitia <[EMAIL PROTECTED]> wrote: > Hi there. > > For most use cases I think about, the iterator protocol is more than enough. > However, on a few cases, I've needed some ugly hacks. > > Ex 1: > > a = iter([1,2,3,4,5]) # assume you got the iterator from a function and > b = iter([1,2,3]) # these two are just examples. > > then, > > zip(a,b) > > has a different side effect from > > zip(b,a) > > After the excecution, in the first case, iterator a contains just [5], on the > second, it contains [4,5]. I think the second one is correct (the 5 was never > used, after all). I tried to implement my 'own' zip, but there is no way to > know the length of the iterator (obviously), and there is also no way > to 'rewind' a value after calling 'next'. > > Ex 2: > > Will this iterator yield any value? Like with most iterables, a construct > > if iterator: > # do something > > would be a very convenient thing to have, instead of wrapping a 'next' call on > a try...except and consuming the first item. > > Ex 3: > > if any(iterator): > # do something ... but the first true value was already consumed and > # cannot be reused. "Any" cannot peek inside the iterator without > # consuming the value. > > Instead, > > i1, i2 = tee(iterator) > if any(i1): > # do something with i2 > > Question/Proposal: > > Has there been any PEP regarding the problem of 'peeking' inside an iterator? > Knowing if the iteration will end or not, and/or accessing the next value, > without consuming it? Is there any (simple, elegant) way around it?
Testing for an empty iterator: http://code.activestate.com/recipes/413614/ There also used to be a more general recipe at the Cookbook but it seems it has not made it to the revamped site. Thanks to the web archive, here's a link: http://web.archive.org/web/20060529065931/http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/304373 HTH, George -- http://mail.python.org/mailman/listinfo/python-list