Skip to content
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

Closed
JustAnotherArchivist opened this issue Dec 8, 2022 · 0 comments
Closed

Unclear documentation of zip()'s strict option #100101

JustAnotherArchivist opened this issue Dec 8, 2022 · 0 comments
Labels
docs Documentation in the Doc dir

Comments

@JustAnotherArchivist
Copy link
Contributor

JustAnotherArchivist commented Dec 8, 2022

In version 3.10, zip() has gained the strict option, which causes a ValueError to be raised when the iterables have different lengths (cf. #84816). The documentation describes this as follows:

Unlike the default behavior, it checks that the lengths of iterables are identical, raising a ValueError if they aren’t:

In my opinion, this is confusing at best. zip() in strict mode does not check the len() 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 if next() on the iterator for one iterable raises a StopIteration, 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 a for ... 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 explicit len() check before running zip() 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:

When enabled, a ValueError is raised if one of the arguments is exhausted before the others.

And likewise in zip()'s docstring:

If strict is true and one of the arguments is exhausted before the others, raise a ValueError.

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() and next(). Even the zip() documentation uses it, but only in the description of the default behaviour without strict. 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

@JustAnotherArchivist JustAnotherArchivist added the docs Documentation in the Doc dir label Dec 8, 2022
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Dec 28, 2022
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Dec 28, 2022
miss-islington added a commit that referenced this issue Dec 28, 2022
(cherry picked from commit cf1c098)

Co-authored-by: JustAnotherArchivist <[email protected]>
miss-islington added a commit that referenced this issue Dec 28, 2022
(cherry picked from commit cf1c098)

Co-authored-by: JustAnotherArchivist <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Documentation in the Doc dir
Projects
None yet
Development

No branches or pull requests

2 participants