← 返回首页
gh-100428: Make int documentation more accurate by hauntsaninja · Pull Request #100436 · python/cpython · GitHub
Skip to content

Navigation Menu

Toggle navigation
Sign in
Appearance settings
Search or jump to...

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Include my email address so I can be contacted
Cancel Submit feedback

Saved searches

Use saved searches to filter your results more quickly

Cancel Create saved search
Appearance settings
Resetting focus

gh-100428: Make int documentation more accurate#100436

Merged
hauntsaninja merged 5 commits into
python:mainfrom
hauntsaninja:gh-100428-int
Jan 2, 2023
Merged

gh-100428: Make int documentation more accurate#100436
hauntsaninja merged 5 commits into
python:mainfrom
hauntsaninja:gh-100428-int

Conversation

hauntsaninja commented Dec 22, 2022 •
edited
Loading

Copy link
Copy Markdown
Contributor
  • Remove first link to lexical definition of integer literal, since it doesn't apply (differs in handling of leading zeros, base needs to be explicitly specified, unicode digits are allowed)
  • Better describe handling of leading zeros and unicode digits
  • Base 0 does not work "exactly" as like a code literal, since it allows unicode digits. Link code literal to lexical definition of integer literal.

pythongh-100428: Make int documentation more accurate …
6678637
- Remove first link to lexical definition of integer literal, since it doesn't apply (differs in handling of leading zeros, base needs to be explicitly specified, unicode digits are allowed) - Better describe handling of leading zeros and unicode digits - Base 0 does not work exactly as like a code literal, since it allows Unicode digits. Link code literal to lexical definition of integer literal.
bedevere-bot mentioned this pull request Dec 22, 2022
Closed
bedevere-bot added awaiting core review docs Documentation in the Doc dir skip news labels Dec 22, 2022
hauntsaninja added needs backport to 3.10 only security fixes needs backport to 3.11 only security fixes labels Dec 22, 2022
mdickinson mentioned this pull request Dec 24, 2022
Merged
mdickinson reviewed Dec 29, 2022
View reviewed changes

mdickinson left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment

Thanks for this PR! Looks good so far, but I think we might need a second pass before it's ready to go in. I've left some comments - discussion welcome!

Comment thread Doc/library/functions.rst Outdated Show resolved Hide resolved
Comment thread Doc/library/functions.rst Outdated
8, 10, or 16, and so that ``int('010', 0)`` is not legal, while
``int('010')`` is, as well as ``int('010', 8)``.
:class:`bytes`, or :class:`bytearray` instance representing an integer
literal in radix *base*. Optionally, the literal can be

mdickinson Dec 29, 2022

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment

Now that we're no longer linking to the Python grammar, I think we could drop the use of literal, which is somewhat misleading. For the first use, [ ...] representing an integer in radix *base* [...] seems clear enough. But other uses might require some more reworking below, though. Rather than expressing in words, it may be clearest to re-introduce a formal grammar production, analogous to what's now in the float description. (Maybe with "digit" as a terminal, where valid digits are then expressed in text.)

Without the link to the grammar, we're also missing information about the rules for underscores. (I'm not suggesting putting that link back in, but rather, finding a way to include the information about underscores in this text.)

Comment thread Doc/library/functions.rst Outdated Show resolved Hide resolved

hauntsaninja commented Jan 1, 2023 •
edited
Loading

Copy link
Copy Markdown
Contributor Author

Thanks for the feedback! Good catch on the underscores. I've made changes to address all your points, except that I haven't added a grammar production. I'm a little hesitant to add one, because I think describing the differences between bases might cause it to be a little long winded in a not especially helpful fashion. If the latest update still feels misleading or is missing detail, I can add one :-)

mdickinson approved these changes Jan 1, 2023
View reviewed changes

mdickinson left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment

LGTM, modulo fixing a missing word in one of the sentences (see comment below).

Thank you!

Comment thread Doc/library/functions.rst Outdated
default *base* is 10. The allowed bases are 0 and 2--36. Base-2, -8, and -16
strings can be optionally prefixed with ``0b``/``0B``, ``0o``/``0O``, or
``0x``/``0X``, as with integer literals in code. For base 0, the string is
interpreted in a similar to an :ref:`integer literal in code <integers>`, in

mdickinson Jan 1, 2023

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment

Missing a word here? Maybe "in a similar way", or "in a similar manner", or just "similarly"

mdickinson commented Jan 1, 2023

Copy link
Copy Markdown
Member

except that I haven't added a grammar production [...]

Sure, either way seems fine. For me, if I were writing this I'd use a grammar production primarily out of laziness - if I'm describing what's happening in English text, I have to examine that text every which way for possible ambiguities, sources of potential reader misunderstanding and imprecisions; with a grammar production, it takes less work to be confident that it expresses the legal syntax clearly and unambiguously.

hauntsaninja merged commit edfbf56 into python:main Jan 2, 2023

miss-islington commented Jan 2, 2023

Copy link
Copy Markdown
Contributor

Thanks @hauntsaninja for the PR 🌮🎉.. I'm working now to backport this PR to: 3.10, 3.11.
🐍🍒⛏🤖

hauntsaninja deleted the gh-100428-int branch January 2, 2023 03:14

bedevere-bot commented Jan 2, 2023

Copy link
Copy Markdown

GH-100674 is a backport of this pull request to the 3.11 branch.

bedevere-bot removed the needs backport to 3.11 only security fixes label Jan 2, 2023
miss-islington pushed a commit to miss-islington/cpython that referenced this pull request Jan 2, 2023
pythongh-100428: Make int documentation more accurate (pythonGH-100436) …
5a399bb
- Remove first link to lexical definition of integer literal, since it doesn't apply (differs in handling of leading zeros, base needs to be explicitly specified, unicode digits are allowed) - Better describe handling of leading zeros, unicode digits, underscores - Base 0 does not work exactly as like a code literal, since it allows Unicode digits. Link code literal to lexical definition of integer literal. (cherry picked from commit edfbf56) Co-authored-by: Shantanu <12621235+hauntsaninja@users.noreply.github.com>

bedevere-bot commented Jan 2, 2023

Copy link
Copy Markdown

GH-100675 is a backport of this pull request to the 3.10 branch.

bedevere-bot removed the needs backport to 3.10 only security fixes label Jan 2, 2023
miss-islington pushed a commit to miss-islington/cpython that referenced this pull request Jan 2, 2023
pythongh-100428: Make int documentation more accurate (pythonGH-100436) …
73163a1
- Remove first link to lexical definition of integer literal, since it doesn't apply (differs in handling of leading zeros, base needs to be explicitly specified, unicode digits are allowed) - Better describe handling of leading zeros, unicode digits, underscores - Base 0 does not work exactly as like a code literal, since it allows Unicode digits. Link code literal to lexical definition of integer literal. (cherry picked from commit edfbf56) Co-authored-by: Shantanu <12621235+hauntsaninja@users.noreply.github.com>
miss-islington added a commit that referenced this pull request Jan 2, 2023
gh-100428: Make int documentation more accurate (GH-100436) …
c92c551
- Remove first link to lexical definition of integer literal, since it doesn't apply (differs in handling of leading zeros, base needs to be explicitly specified, unicode digits are allowed) - Better describe handling of leading zeros, unicode digits, underscores - Base 0 does not work exactly as like a code literal, since it allows Unicode digits. Link code literal to lexical definition of integer literal. (cherry picked from commit edfbf56) Co-authored-by: Shantanu <12621235+hauntsaninja@users.noreply.github.com>
miss-islington added a commit that referenced this pull request Jan 2, 2023
gh-100428: Make int documentation more accurate (GH-100436) …
af136e9
- Remove first link to lexical definition of integer literal, since it doesn't apply (differs in handling of leading zeros, base needs to be explicitly specified, unicode digits are allowed) - Better describe handling of leading zeros, unicode digits, underscores - Base 0 does not work exactly as like a code literal, since it allows Unicode digits. Link code literal to lexical definition of integer literal. (cherry picked from commit edfbf56) Co-authored-by: Shantanu <12621235+hauntsaninja@users.noreply.github.com>
hauntsaninja added a commit to hauntsaninja/cpython that referenced this pull request Apr 30, 2023
Improve int test coverage …
df988c1
Following discussion in https://discuss.python.org/t/bug-in-int-42/26360/5 This tests some of the things documented in python#100436
hauntsaninja mentioned this pull request Apr 30, 2023
Merged
hauntsaninja added a commit that referenced this pull request May 1, 2023
Improve int test coverage (#104024) …
69bc86c
Following discussion in https://discuss.python.org/t/bug-in-int-42/26360/5 This tests some of the things documented in #100436 Co-authored-by: Gregory P. Smith <greg@krypto.org>
miss-islington mentioned this pull request May 1, 2023
Merged
miss-islington pushed a commit to miss-islington/cpython that referenced this pull request May 1, 2023
Improve int test coverage (pythonGH-104024) …
2bee583
Following discussion in https://discuss.python.org/t/bug-in-int-42/26360/5 This tests some of the things documented in python#100436 (cherry picked from commit 69bc86c) Co-authored-by: Shantanu <12621235+hauntsaninja@users.noreply.github.com> Co-authored-by: Gregory P. Smith <greg@krypto.org>
hauntsaninja added a commit that referenced this pull request May 1, 2023
[3.11] Improve int test coverage (GH-104024) (#104026) …
2be3656
Improve int test coverage (GH-104024) Following discussion in https://discuss.python.org/t/bug-in-int-42/26360/5 This tests some of the things documented in #100436 (cherry picked from commit 69bc86c) Co-authored-by: Shantanu <12621235+hauntsaninja@users.noreply.github.com> Co-authored-by: Gregory P. Smith <greg@krypto.org>
This file contains hidden or 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
Show hidden characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

1 more reviewer
mdickinson mdickinson approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

docs Documentation in the Doc dir skip news

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

Footer

© 2026 GitHub, Inc.