GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — as_integer_ratio docstring's · Issue #101825 · python/cpython

as_integer_ratio docstring's #101825

New issue
Copy link
New issue
Copy link
Closed
Closed
as_integer_ratio docstring's#101825
Copy link
Labels
docsDocumentation in the Doc dirDocumentation in the Doc dir

Description

@skirpichev
skirpichev
opened on Feb 11, 2023
Issue body actions

For builtin/stdlib types we have

int:

    Return integer ratio.

    Return a pair of integers, whose ratio is exactly equal to the original int
    and with a positive denominator.

Fraction:

as_integer_ratio(self)
    Return the integer ratio as a tuple.

    Return a tuple of two integers, whose ratio is equal to the
    Fraction and with a positive denominator.

float:

    Return integer ratio.

    Return a pair of integers, whose ratio is exactly equal to the original float
    and with a positive denominator.

Decimal:

    Return a pair of integers, whose ratio is exactly equal to the original
    Decimal and with a positive denominator. The ratio is in lowest terms.
    Raise OverflowError on infinities and a ValueError on NaNs.

All methods actually return a pair, whose ratio is in lowest terms, but only the last docstring says this explicitly. Shouldn't other methods do same? (Taken from this.)

Edit: Ditto for some sphinx docs, e.g. for the float.as_integer_ratio(): "Return a pair of integers whose ratio is exactly equal to the original float and with a positive denominator. Raises OverflowError on infinities and a ValueError on NaNs."

Linked PRs

  • gh-101825: mention, that as_integer_ratio() output is normalized #101843
Reacted by Owain Davies

Activity

  1. skirpichev
    added
    docsDocumentation in the Doc dirDocumentation in the Doc dir
    on Feb 11, 2023
  2. skirpichev
    added 2 commits that reference this issue on Feb 12, 2023

    pythongh-101825: mention, that as_integer_ratio() output is normalized

    9c54422

    pythongh-101825: mention, that as_integer_ratio() output is normalized

    d3de603
  3. mdickinson
    added a commit that references this issue on Feb 27, 2023

    gh-101825: Clarify that as_integer_ratio() output is always normalized (

    4624987

  4. mdickinson commented on Feb 27, 2023

    @mdickinson
    mdickinson
    on Feb 27, 2023
    Member
    More actions

    Closed in #101843.

  5. mdickinson
    closed this as completedon Feb 27, 2023
  6. carljm
    added a commit that references this issue on Feb 28, 2023

    Merge branch 'main' into inlinecomp2

    73dc0ed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    docsDocumentation in the Doc dirDocumentation in the Doc dir

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions
      You are visitor 01402503 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.