Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we care how this handles strange iterators that keep going after having raised
StopIteration?Maybe the
Py_CLEAR(bo->it)could be moved to before thisbreak;.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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:
That said, I'm not really sure about this one and could easily be persuaded to add a
Py_CLEAR(bo->it)to the code path for the short list.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does seem like an edge case that could go either way.
I'm noticing that some iterators do
Py_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:
Clear the iterator immediately after any internal
next()call fails, similar topairwise,islice,chain, andcycle(sort of).Never clear the iterator and remove the
if (it == NULL)check altogether, similar todropwhile,takewhile,accumulate,compress,zipandenumerate. 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 the
Py_CLEARand theNULLcheck is most natural?