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

gh-100428: Make int documentation more accurate #100436

Merged
merged 5 commits into from
Jan 2, 2023

Conversation

hauntsaninja
Copy link
Contributor

@hauntsaninja hauntsaninja commented Dec 22, 2022

  • 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.

- 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.
Copy link
Member

@mdickinson mdickinson left a comment

Choose a reason for hiding this comment

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

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!

Doc/library/functions.rst Outdated Show resolved Hide resolved
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
Copy link
Member

Choose a reason for hiding this comment

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

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.)

Doc/library/functions.rst Outdated Show resolved Hide resolved
@hauntsaninja
Copy link
Contributor Author

hauntsaninja commented Jan 1, 2023

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 :-)

Copy link
Member

@mdickinson mdickinson left a comment

Choose a reason for hiding this comment

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

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

Thank you!

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
Copy link
Member

Choose a reason for hiding this comment

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

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

@mdickinson
Copy link
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 hauntsaninja merged commit edfbf56 into python:main Jan 2, 2023
@miss-islington
Copy link
Contributor

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

@hauntsaninja hauntsaninja deleted the gh-100428-int branch January 2, 2023 03:14
@bedevere-bot
Copy link

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

@bedevere-bot 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
- 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
Copy link

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

@bedevere-bot 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
- 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
- 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
- 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
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 added a commit that referenced this pull request May 1, 2023
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 pushed a commit to miss-islington/cpython that referenced this pull request May 1, 2023
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
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>
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 skip news
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants