-
-
Notifications
You must be signed in to change notification settings - Fork 30.8k
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
bpo-37819: Add Fraction.as_integer_ratio() #15212
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.
I would change "exactly equal" to just "equal" -- there's nothing to be gained by adding "exactly".
Doc/library/fractions.rst
Outdated
@@ -94,6 +94,13 @@ another rational number, or from a string. | |||
Denominator of the Fraction in lowest term. | |||
|
|||
|
|||
.. method:: as_integer_ratio() | |||
|
|||
Return a tuple of integers, whose ratio is exactly equal |
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.
Drop "exactly"
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.
@gvanrossum To some degree, I think that mentioning "exactly" might help readers to understand the advantage of using an integer ratio when they need more precision. However, there might be a better way to mention this.
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. I'll drop this "exactly". The wording was take from the docstring for float.as_integer_ratio() but in makes a lot more sense.
Lib/fractions.py
Outdated
def as_integer_ratio(self): | ||
"""Return integer ratio. | ||
|
||
Return a pair of integers, whose ratio is exactly equal to the original |
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.
Ditto.
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.
Will do.
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 for the PR @rhettinger.
I had some minor suggestions:
@@ -0,0 +1,2 @@ | |||
Add Fraction.as_integer_ratio() to match the corresponding methods in bool, |
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.
Would it be helpful to provide a link to the method using inline markup? This would allow readers to easily find the documentation for the new method.
Also regarding this line, as far as I'm aware, there's not a bool.as_integer_ratio() method. To confirm this, I used git grep to search the documentation:
As expected, it returned the methods for decimal, int, and float but nothing for bool.
Add Fraction.as_integer_ratio() to match the corresponding methods in bool, | |
Add :meth:`Fraction.as_integer_ratio` to match the corresponding methods in |
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.
We don't have to provide cross-links from Misc/NEWS. It is okay for entries there to be plain text.
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.
@rhettinger Oh yeah it's okay either way, but since the Misc/NEWS entries support reST and Sphinx I think it's helpful to include links to functions, methods, or classes that were modified in functionality or documentation. Usually the news entries are very brief, so if a curious reader wants to get more information they can simply use the link.
To those of us who are familiar with the structuring of the documentation, it's usually easy to find the relevant sections. But, some less familiar or newer readers might have trouble doing so, especially if they use an external search engine (which frequently will lead them to the 2.7 docs or an incorrect page).
It's more a convenience/QoL addition for the readers than anything, and I don't think it hurts the readability or takes much effort from our end. I might start a thread over on python-dev to see what the others think. Not at all for this PR specifically, but just in general.
Edit: Just realized that I can't start threads on the Python-Dev list. I'll open a new topic on Discuss instead, let me know if you'd like a link to the thread. Never mind, I'm able to create a new thread on the ML. I'll do so later tonight, in the meantime here's the discuss post: https://discuss.python.org/t/should-news-entries-contain-documentation-links/2127
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.
Also, what was the conclusion on bool
being in the news entry? From my understanding, there is not a bool.as_integer_ratio()
method.
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.
@aeros167 Have you validated your understanding?
From my understanding, bool inherits from int. If int has as_integer_ratio()
, bool should have it too.
$ ./python
Python 3.9.0a0 (heads/master:e95ac20103, Jul 24 2019, 21:48:01)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> i = 42
>>> i.as_integer_ratio()
(42, 1)
>>> True.as_integer_ratio()
(1, 1)
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.
@methane Thanks for the explanation!
At first this didn't make sense to me, but then I remembered that:
>>> int(True)
1
>>> int(False)
0
>>> True == 1
True
>>> False == 0
True
So it makes sense that the boolean values would also have the int methods, since they are effectively specialized ints. I was just confused at first since I could not find an explicit mention of bool.is_integer_ratio()
in the docs, but I suppose it doesn't need to be mentioned since as you said, bool inherits from int.
Lib/fractions.py
Outdated
def as_integer_ratio(self): | ||
"""Return integer ratio. | ||
|
||
Return a pair of integers, whose ratio is exactly equal to the original |
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.
Would it be potentially helpful to readers to specify in the doc-string that the integer pair is returned as a tuple? This is not uncommonly done, but I think it's worthwhile to specifically mention this:
Return a pair of integers, whose ratio is exactly equal to the original | |
Return a tuple containing two integers, whose ratio is exactly equal to the original |
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.
Will do.
@@ -302,6 +302,12 @@ def testFromDecimal(self): | |||
ValueError, "cannot convert NaN to integer ratio", | |||
F.from_decimal, Decimal("snan")) | |||
|
|||
def test_as_integer_ratio(self): |
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.
I did a comparison of these tests to the existing ones, and noticed that test_decimal.py
contains coverage for attempting to convert inf (inf = 1e1000
), -inf, nan (nan = inf - inf
), and an invalid string to an integer ratio:
def test_as_integer_ratio(self):
Decimal = self.decimal.Decimal
# exceptional cases
self.assertRaises(OverflowError,
Decimal.as_integer_ratio, Decimal('inf'))
self.assertRaises(OverflowError,
Decimal.as_integer_ratio, Decimal('-inf'))
self.assertRaises(ValueError,
Decimal.as_integer_ratio, Decimal('-nan'))
self.assertRaises(ValueError,
Decimal.as_integer_ratio, Decimal('snan123'))
For the sake of consistency, should we include that here as well? I'm not certain that it's necessary, but I figured it was worth mentioning.
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.
No need. Fractions don't have that concept.
I didn't include this in my review since it's not directly related to the PR, but I noticed some minor inconsistencies in the tests between the different versions of self.assertRaises(ValueError,
Decimal.as_integer_ratio, Decimal('snan123')) Also, as far as I can tell, there's no test coverage at all for the int version of the method. Should I open a new issue for this? |
* The other methods spell fraction with a capital F. * The word "original" doesn't make sense because the original fraction is reduced: Fraction(4, 6).as_integer_ratio() |-> (2, 3)
Thanks @rhettinger for the PR 🌮🎉.. I'm working now to backport this PR to: 3.8. |
(cherry picked from commit f03b4c8) Co-authored-by: Raymond Hettinger <rhettinger@users.noreply.github.com>
GH-15215 is a backport of this pull request to the 3.8 branch. |
Should this |
https://bugs.python.org/issue37819