-
-
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
gh-101021: Document binary parameters as bytes #101024
Conversation
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.
Can you resolve the conflicts and make sure all the checks pass? Since this is a just a docstring change, adding the skip-news
label is probably fine.
This could probably be backported to maintenance branches.
Have you checked the actual stdlib documentation for its language?
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
3ae1c6d
to
5fe70e4
Compare
The existing documentation refers to binary parameters as "strings" when they are actually bytes. Fixes python#101021
5fe70e4
to
ae1b8b7
Compare
I have made the requested changes; please review again. |
Thanks for making the requested changes! @warsaw: please review the changes made to this pull request. |
For your question about the labels, if you can't actually change labels using the 'labels' section in the right column of the PR on the github web interface, then you don't have permission to change those labels. If I'm right about that then Barry probably just forgot that regular users can't make such changes. On the subject of the documentation, the answer is that the Python documentation is not so much documentation of the cpython interpreter and the standard library as it is a specification of the Python language and the standard library. (This fact is sometimes forgotten and results in later doc fixes prompted by people from other implementations of python noticing a statement that is cpython specific but not marked as such.) While it would be technically possible to have the documentation for things written in python be docstrings extracted into the specification docs, it has so far been deemed undesirable to do that. I think this is a combination of the aforementioned specification nature of the docs leading to a desire to be consistent (all the docs are in the doc source tree, not just some of them, to emphasize their independence from the specific implementation), and the fact that the language in the specification version of the docs, while often very similar or even identical to the function descriptions in the docstrings, is often enough different from what you would write if you were thinking of the function doc as a standalone docstring. Including the fact that we prefer to not have sphinx markup in docstrings. |
Thanks, David. Love your avatar. Might be a good idea to teach the bots (if not the maintainers) not to nag contributors to do something they aren't allowed to do. 😉 I understand your explanation of how the documentation system works, and I agree that what you've described is probably the right approach. One of the costs of that approach, though, is that it increases the work for keeping the documentation current and in sync with itself (and the likelihood that problems like the one being fixed here will persist). Oh, well. Life involves tradeoffs. 😅 |
I was trying to look through the dev guide to find a description of permissions for labeling. I think the closest it gets is in the triage team description. So yes, @bitdancer is probably right that @bkline doesn't have permission to add labels. Normally in my own libraries, I extract API documentation from docstrings and type hints, but even with that, it's difficult to describe the APIs with the level of detail necessary for the standard library. |
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.
Thanks again for your contribution @bkline. Everything looks great.
(cherry picked from commit 49cae39) Co-authored-by: Bob Kline <bkline@users.noreply.github.com>
Sorry, @bkline and @warsaw, I could not cleanly backport this to |
GH-101043 is a backport of this pull request to the 3.11 branch. |
@bkline - as you can see, the automation couldn't backport the change. If you're able to do that and submit a PR, I can help get that landed. If you can't or don't want to, let me know and I'll try to get to it when I'm back on my laptop. |
I'd be willing to give it a shot, given adequate instructions. Not 100% sure I'd know all the steps which are needed otherwise. Fortunately, Google has gotten a lot better about bringing up the most current version of the docs in response to searches, so it's not as critical as the backport to 3.11 (which succeeded). Short answer: we're probably better off if you do it. 😎 |
@bkline The devguide does explain how to manually backport changes. It's entirely up to you - if you want to learn how to do it and it would be fun for you, go for it! Just tag me in the PR. If not, I'll give it a shot. |
Now that I'm on my desktop, I can see that the 3.11 backport worked fine. I've approved and merged it. It's only the 3.10 backport that failed. I'm looking at that now. |
@warsaw Yes, those look like excellent instructions. I will definitely give it a shot. |
Well, not as much fun as we thought it would be.
I think I'll leave this to the big dogs. 😆🐾 |
GH-101052 is a backport of this pull request to the 3.10 branch. |
Yeah, I'm sorry about all the friction. I ran into a few things myself so at least the core devs have also had a good discussion about this experience. That all aside, I was able to manually backport the change the 3.10, so we're all done here. Thanks again for your contribution! |
No worries, and thanks for all your help (and for helping to keep Python the best of the many languages I've used over the decades). |
The existing documentation refers to binary parameters as "strings" when they are actually bytes.
Fixes #101021