[Python-ideas] Add lookahead iterator (peeker) to itertools

Ron Adam ron3200 at gmail.com
Wed Feb 27 02:50:17 CET 2013



On 02/26/2013 03:57 PM, Terry Reedy wrote:

>> I would prefer a .error flag, along with a .next_value attribute.  It
>> would make the code using it easier to follow.
>
> Not clear to me, but a minor detail.
>
>>       it.error        <--    True if next(it) will raise an exception.
>>       it.next_value   <--    The next value, or the exception to raise.
>
>
>> About it.error.  If it was a concurrent version, then it.error could
>> have three values.
>>
>>       it.error == True   # Will raise an exception
>>       it.error == False  # Will not raise an exception
>>       it.error == None   # Still calculating
>>
>> I wonder how this type of generator will behave with "yield from".
>
> lookaheads are iterators, but not generators and 'yield from' requires a
> generator. A generator function could recompute items to yield, but it
> cannot add methods or attributes to the generator instances it will produce.

Yep, I missed that point.

I was thinking it may be more useful in the case of generators along with 
yield from, but it isn't as straight forward as the iterator case as you 
correctly pointed out.

(More or less just thinking out loud at this point.)

My intuition/feelings was that in both the cases of a look-ahead iterator 
and a calc-ahead generator, (if we could manage that), should act the same 
in as many ways as possible.   And a calc-ahead generator should act like a 
concurrent instance.   The reason for thinking that is, it would allow the 
calc-ahead generator instance to be replaced with a concurrent instance 
without changing anything.

So if (in theory) a concurrent generator instance wouldn't hold exceptions, 
then your look-ahead iterator shouldn't also.  But if everything happens on 
the next and send calls, then it makes handling exceptions a bit easier as 
you don't have to special case the instance creation part.

But iterators don't necessarily need to match all generator behaviours, 
It's just may preference that they do as much as possible.  :-)

Of course Guido may have something in what he's doing now that would be 
very much like this.  A kind of "futures" generator.  I've been away from 
these boards for a while and haven't caught up with everything yet.

Cheers,
    Ron




More information about the Python-ideas mailing list