Repository navigation
gh-142732: Prevent reentrancy in itertools.zip_longest - #150675
brijkapadia wants to merge 5 commits into
Conversation
Adds a check in `functools.zip_longest` that raises a `ValueError` when a reentrancy is detected.
brijkapadia
changed the title
functools.zip_longestitertools.zip_longest
| return NULL; | ||
| if (lz->numactive == 0) | ||
| if (lz->running == 1) { | ||
| PyErr_SetString(PyExc_ValueError, |
There was a problem hiding this comment.
itertools.tee raises a RuntimeError, but generators raise a ValueError on re-entrant calls. In #150589 I picked RuntimeError for pairwise re-entrant calls.
I have no strong opinion on the type of error, but lets make it an informed decision and then be consistent. @rhettinger
There was a problem hiding this comment.
@eendebakpt @rhettinger Has there been any update yet on what error is best to raise?
| @@ -0,0 +1 @@ | |||
| Now :func:`itertools.zip_longest` raises an :exc:`ValueError` when a reentrancy is detected. | |||
There was a problem hiding this comment.
This is a behaviour change. I think we should add an entry to the 3.16 whatsnew (https://docs.python.org/3.16/whatsnew/3.16.html). Can be done in a follow PR once we know which other iterators are changed.
Co-authored-by: Pieter Eendebak <pieter.eendebak@gmail.com>
|
@rhettinger Would you be able to review the PR? I think the prevention of reentrancy is according to your suggestions, but you may have different ideas about the implementation. |
2 participants
Adds a check in
itertools.zip_longestthat raises aValueErrorwhen a reentrancy is detected.itertools.zip_longest_next/islice/batchedvia re-entrant iterator #142732