bpo-40636: Clarify the zip built-in docstring. #20118
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This puts much simpler text up front along with an example. As it was, the zip built-in docstring was technically correct. But too technical for the reader who shouldn't _need_ to know about `__next__` and `StopIteration` as most people do not need to understand the internal implementation details of the iterator protocol in their daily life. This is a documentation only change, intended to be backported to 3.8; it is only tangentially related to PEP-618 which might offer new behavior options in the future.
gpshead
commented
May 15, 2020
|
I really like the docstring for |
This gets rid of the legacy wording paragraph which seems too tied to implementation details of the iterator protocol which isn't relevant here.
My zip docstring contains a doctest example.
|
Good suggestion, take a look at the latest proposed wording. |
gpshead
commented
May 15, 2020
brandtbucher
requested changes
May 15, 2020
Co-authored-by: Brandt Bucher <brandtbucher@gmail.com>
Co-authored-by: Brandt Bucher <brandtbucher@gmail.com>
Co-authored-by: Brandt Bucher <brandtbucher@gmail.com>
|
good suggestios, this is looking good. |
brandtbucher
approved these changes
May 15, 2020
|
Thanks @gpshead for the PR 🌮🎉.. I'm working now to backport this PR to: 3.7, 3.8. |
miss-islington
pushed a commit
to miss-islington/cpython
that referenced
this pull request
May 15, 2020
Clarify the zip built-in docstring. This puts much simpler text up front along with an example. As it was, the zip built-in docstring was technically correct. But too technical for the reader who shouldn't _need_ to know about `__next__` and `StopIteration` as most people do not need to understand the internal implementation details of the iterator protocol in their daily life. This is a documentation only change, intended to be backported to 3.8; it is only tangentially related to PEP-618 which might offer new behavior options in the future. Wording based a bit more on enumerate per Brandt's suggestion. This gets rid of the legacy wording paragraph which seems too tied to implementation details of the iterator protocol which isn't relevant here. Co-authored-by: Brandt Bucher <brandtbucher@gmail.com> (cherry picked from commit 6a5d3ff) Co-authored-by: Gregory P. Smith <greg@krypto.org>
|
GH-20124 is a backport of this pull request to the 3.8 branch. |
|
Sorry, @gpshead, I could not cleanly backport this to |
miss-islington
added a commit
that referenced
this pull request
May 15, 2020
Clarify the zip built-in docstring. This puts much simpler text up front along with an example. As it was, the zip built-in docstring was technically correct. But too technical for the reader who shouldn't _need_ to know about `__next__` and `StopIteration` as most people do not need to understand the internal implementation details of the iterator protocol in their daily life. This is a documentation only change, intended to be backported to 3.8; it is only tangentially related to PEP-618 which might offer new behavior options in the future. Wording based a bit more on enumerate per Brandt's suggestion. This gets rid of the legacy wording paragraph which seems too tied to implementation details of the iterator protocol which isn't relevant here. Co-authored-by: Brandt Bucher <brandtbucher@gmail.com> (cherry picked from commit 6a5d3ff) Co-authored-by: Gregory P. Smith <greg@krypto.org>
arturoescaip
pushed a commit
to arturoescaip/cpython
that referenced
this pull request
May 24, 2020
Clarify the zip built-in docstring. This puts much simpler text up front along with an example. As it was, the zip built-in docstring was technically correct. But too technical for the reader who shouldn't _need_ to know about `__next__` and `StopIteration` as most people do not need to understand the internal implementation details of the iterator protocol in their daily life. This is a documentation only change, intended to be backported to 3.8; it is only tangentially related to PEP-618 which might offer new behavior options in the future. Wording based a bit more on enumerate per Brandt's suggestion. This gets rid of the legacy wording paragraph which seems too tied to implementation details of the iterator protocol which isn't relevant here. Co-authored-by: Brandt Bucher <brandtbucher@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This puts much simpler text up front along with an example.
As it was, the zip built-in docstring was technically correct. But too
technical for the reader who shouldn't need to know about
__next__andStopIterationas most people do not need to understand the internalimplementation details of the iterator protocol in their daily life.
This is a documentation only change, intended to be backported to 3.8; it is
only tangentially related to PEP-618 which might offer new behavior options
in the future.
https://bugs.python.org/issue40636