Do we care how this handles strange iterators that keep going after having raisedStopIteration?

>>> from itertools import batched>>> class A:...     def __init__(self):...         self.i = 0...     def __iter__(self):...         return self...     def __next__(self):...         i = self.i...         self.i += 1...         if i == 7:...             raise StopIteration()...         return i...>>> x = batched(A(), 5)>>> next(x)[0, 1, 2, 3, 4]>>> next(x)[5, 6]>>> next(x)[8, 9, 10, 11, 12]

Maybe thePy_CLEAR(bo->it) could be moved to before thisbreak;.

I'm thinking of leaving this as is. The current PR matches the behavior of the pure python version and the strange iterator works the same way with other tools:

>>> it = zip(range(10), A())>>> list(it)[(0, 0), (1, 1), (2, 2), (3, 3), (4, 4), (5, 5), (6, 6)]>>> list(it)[(8, 8), (9, 9)]>>> it = enumerate(A())>>> list(it)[(0, 0), (1, 1), (2, 2), (3, 3), (4, 4), (5, 5), (6, 6)]>>> next(it)(7, 8)>>> next(it)(8, 9)

That said, I'm not really sure about this one and could easily be persuaded to add aPy_CLEAR(bo->it) to the code path for the short list.

This does seem like an edge case that could go either way.

I'm noticing that some iterators doPy_CLEAR(obj->it) as soon as thenext() call fails, while other objects have internal iterators that are never NULL. My concern is thatbatched() clears the iterator sometimes (when the firstnext() of a batch fails), but not other times (when a subsequentnext() fails).

So I would think to do one or the other, but not both:

1. Clear the iterator immediately afterany internalnext() call fails, similar topairwise,islice,chain, andcycle (sort of).

2. Never clear the iterator and remove theif (it == NULL) check altogether, similar todropwhile,takewhile,accumulate,compress,zip andenumerate. Unfortunately, it would mean allocating and throwing awayPyList_New(n), but that's in the rare case that someone is abusing the iterator.

Maybe removing thePy_CLEAR and theNULL check is most natural?