An iterator with look-ahead

[Neil Cerutti]

For use in a hand-coded parser I wrote the following simple
iterator with look-ahead. I haven't thought too deeply about what
peek ought to return when the iterator is exhausted. Suggestions
are respectfully requested. As it is, you can't be sure what a
peek() =None signifies until the next iteration unless you
don't expect None in your sequence.

Using itertools.tee is the alternative I thought about, but
caveates in the documentation disuaded me.

class LookAheadIter(o bject):
""" An iterator with the a peek() method, so you can see what's coming next.

If there is no look-ahead, peek() returns None.

>>nums = [1, 2, 3, 4, 5]
look = LookAheadIter(n ums)
for a in look:

... print (a, look.peek())
(1, 2)
(2, 3)
(3, 4)
(4, 5)
(5, None)
"""
def __init__(self, data):
self.iter = iter(data)
self.look = self.iter.next( )
self.exhausted = False
def __iter__(self):
return self
def peek(self):
if self.exhausted:
return None
else:
return self.look
def next(self):
item = self.look
try:
self.look = self.iter.next( )
except StopIteration:
if self.exhausted:
raise
else:
self.exhausted = True
return item

--
Neil Cerutti
We've got to pause and ask ourselves: How much clean air do we really need?
--Lee Iacocca

[Neil Cerutti]

On 2007-01-10, Fredrik Lundh <fr*****@python ware.comwrote:

if you're doing simple parsing on an iterable, it's easier and
more efficient to pass around the current token and the
iterator's next method:

http://online.effbot.org/2005_11_01_...imple-parser-1

Thank you. Much better.

--
Neil Cerutti

[George Sakkis]

Neil Cerutti wrote:

For use in a hand-coded parser I wrote the following simple
iterator with look-ahead. I haven't thought too deeply about what
peek ought to return when the iterator is exhausted. Suggestions
are respectfully requested. As it is, you can't be sure what a
peek() =None signifies until the next iteration unless you
don't expect None in your sequence.

There is a different implementation in the Cookbook already:
http://aspn.activestate.com/ASPN/Coo.../Recipe/304373

George

[Steven Bethard]

Neil Cerutti wrote:

For use in a hand-coded parser I wrote the following simple
iterator with look-ahead.

There's a recipe for this:

http://aspn.activestate.com/ASPN/Coo.../Recipe/304373

Note that the recipe efficiently supports an arbitrary look-ahead, not
just a single item.

I haven't thought too deeply about what peek ought to return
when the iterator is exhausted. Suggestions are respectfully
requested.

In the recipe, StopIteration is still raised on a peek() operation that
tries to look past the end of the iterator.

STeVe

[Neil Cerutti]

On 2007-01-10, Steven Bethard <st************ @gmail.comwrote :

Neil Cerutti wrote:

>For use in a hand-coded parser I wrote the following simple
iterator with look-ahead.

There's a recipe for this:

http://aspn.activestate.com/ASPN/Coo.../Recipe/304373

Note that the recipe efficiently supports an arbitrary
look-ahead, not just a single item.

>I haven't thought too deeply about what peek ought to return
when the iterator is exhausted. Suggestions are respectfully
requested.

In the recipe, StopIteration is still raised on a peek()
operation that tries to look past the end of the iterator.

That was all I could think of as an alternative, but that makes
it fairly inconvenient to use. I guess another idea might be to
allow user to provide a "no peek" return value in the
constructor, if they so wish.

--
Neil Cerutti

[Paddy]

Neil Cerutti wrote:

On 2007-01-10, Steven Bethard <st************ @gmail.comwrote :

Neil Cerutti wrote:

For use in a hand-coded parser I wrote the following simple
iterator with look-ahead.

There's a recipe for this:

http://aspn.activestate.com/ASPN/Coo.../Recipe/304373

Note that the recipe efficiently supports an arbitrary
look-ahead, not just a single item.

I haven't thought too deeply about what peek ought to return
when the iterator is exhausted. Suggestions are respectfully
requested.

In the recipe, StopIteration is still raised on a peek()
operation that tries to look past the end of the iterator.

That was all I could think of as an alternative, but that makes
it fairly inconvenient to use. I guess another idea might be to
allow user to provide a "no peek" return value in the
constructor, if they so wish.

--
Neil Cerutti

You could raise a different Exception, PeekPastEndEcep tion ?
- Paddy.