Add a "peekable" iterator adaptor, with a peek() method that returns the next element.

[bluss]

Peekable changes by @SimonSapin and original PR is #8396

[bluss]

The naming collision is now real, with IteratorUtil and Iterator merged, the old .peek() and new .peek() have the same method name.

• Remove the old peek since it's pretty useless (can be accomplished with1 filter)?
• Rename one of the two .peek? I was thinking of the slightly cheeky .manhole() for the preexisting .peek()

[bluss]

Rebased to cope with the (awesome) iterator changes merged inbetween. I squashed the rename of PeekableIterator -> Peekable together with the introduction of peekable, to make conflict resolution when rebasing easier.

[Kimundi]

Hm, just an idea: This Iterator basically buffers one element for the peek() function, right?

We could just have a generic BufferIterator that buffers N elements, and that has the ability to peek N elements into the future. Of course, that would either have to allocate for the internal vector, or require uints in the typesystem so that it can use embedded [T, ..N] vectors, so it's probably not worth doing right now.

[bluss]

I think lookahead or peek is the better name, but sure it's an idea kimundi, but we can't implement it easily.

[SimonSapin]

@Kimundi it only buffers when you call peek(). If you don’t, self.peeked is always None and next() just defers to self.iter.next(). I suppose we could make the code simpler by always buffering one element, but that’s consuming the underlying iterator more than we have to. I don’t know which is better.

As to peek(n), yes that could be useful as well but as you say not as obvious to implement. (I also personally don’t need it yet.)