-
-
Notifications
You must be signed in to change notification settings - Fork 31k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unclear documentation of zip()
's strict
option
#100101
Labels
docs
Documentation in the Doc dir
Comments
brandtbucher
pushed a commit
that referenced
this issue
Dec 28, 2022
This was referenced Dec 28, 2022
miss-islington
pushed a commit
to miss-islington/cpython
that referenced
this issue
Dec 28, 2022
…GH-100103) (cherry picked from commit cf1c098) Co-authored-by: JustAnotherArchivist <JustAnotherArchivist@users.noreply.github.com>
miss-islington
pushed a commit
to miss-islington/cpython
that referenced
this issue
Dec 28, 2022
…GH-100103) (cherry picked from commit cf1c098) Co-authored-by: JustAnotherArchivist <JustAnotherArchivist@users.noreply.github.com>
miss-islington
added a commit
that referenced
this issue
Dec 28, 2022
miss-islington
added a commit
that referenced
this issue
Dec 28, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In version 3.10,
zip()
has gained thestrict
option, which causes aValueError
to be raised when the iterables have different lengths (cf. #84816). The documentation describes this as follows:In my opinion, this is confusing at best.
zip()
instrict
mode does not check thelen()
of the iterables, as that sentence might lead one to think. Rather – and exactly as I expected before reading the documentation – it checks that all iterables are exhausted at the same time (or more specifically, it checks that ifnext()
on the iterator for one iterable raises aStopIteration
, the others do as well). This distinction is important in the context of iterables that do not have a length, e.g. generator functions. It also makes it clear that the error is only raised when one of the iterables reaches exhaustion, which may be important e.g. in afor ... in zip(...)
loop, since the loop body would be executed for the matching pairs before an error is raised. Depending on what the user is doing, they may therefore still want an explicitlen()
check before runningzip()
to avoid having to roll back later, for example.Note that PEP-618 (which is not linked from the docs) does not contain this misleading language:
And likewise in
zip()
's docstring:I think this language of an 'exhausted iterable' should be used in the documentation as well. It is already used for other core functions such as
map()
andnext()
. Even thezip()
documentation uses it, but only in the description of the default behaviour withoutstrict
. I feel like, compared to the two quotes above, the timing of the exception deserves an extra explanation though.I will submit a PR with my proposed changes shortly.
Linked PRs
The text was updated successfully, but these errors were encountered: