bpo-33073: Adding as_integer_ratio to ints. #8750

lisroach · 2018-08-12T23:37:05Z

Adding as_integer_ratio to ints to make them more interoperable with floats.

https://bugs.python.org/issue33073

pablogsal · 2018-08-13T01:44:08Z

Objects/longobject.c

+    PyObject *result_pair = NULL;
+
+    denominator = PyLong_FromLong(1);
+    result_pair = PyTuple_Pack(2, self, denominator);


If PyLong_FromLong returns NULL then PyTuple_Pack and Py_DECREF(denominator) will fail.

I think the whole function can be replaced with return PyTuple_Pack(2, self, _PyLong_One).

@pablogsal But PyLong_FromLong always receive the 1. How could it fail?

The contract of PyLong_FromLong says that it can return NULL on failure. Even if the current implementation (that uses the array of small ints) makes it improbable/impossible to fail, this can change in the future without changing the external API.

eric-wieser · 2018-08-13T06:07:42Z

Objects/longobject.c

+Return a pair of integers, whose ratio is exactly equal to the original int
+and with a positive denominator.
+
+Raise OverflowError on infinities and a ValueError on NaNs.


An int can never be any of these things - remove this line

Yes. math.inf is float class

eric-wieser · 2018-08-13T06:08:14Z

Lib/test/test_long.py

+    def test_as_integer_ratio(self):
+        tests = [10, 0, -10, 1, 3]
+        for value in tests:
+            self.assertEqual((value).as_integer_ratio(), (value, 1))


nit: no parens needed around value

ZackerySpytz · 2018-08-14T05:59:36Z

Doc/library/stdtypes.rst

+  Return a pair of integers whose ratio is exactly equal to the original integer
+  and with a positive denominator. The integer ratio of integers (whole numbers)
+  is always the integer as the numerator and 1 as the denominator.
+


A versionadded directive needs to be added. Also, the developer's guide states that reST files should use an indentation of 3 spaces.

mdickinson · 2018-08-17T18:14:35Z

Objects/longobject.c

+int_as_integer_ratio_impl(PyObject *self)
+/*[clinic end generated code: output=e60803ae1cc8621a input=ce9c7768a1287fb9]*/
+{
+  return PyTuple_Pack(2, self, _PyLong_One)


There's a missing semicolon at the end of this line; I think that's why the continuous integration builds are failing.

Also, please change the indentation of this line to 4 spaces instead of 2 spaces, following PEP7. Thanks!

…r_ratio.

mdickinson · 2018-08-25T11:40:20Z

@lisroach Thanks for the update. I've pushed a commit that should fix the failing test_doctest.

mdickinson

@lisroach If you're okay with my recent updates, I think this PR is ready to merge.

serhiy-storchaka · 2018-08-25T15:05:37Z

Objects/longobject.c

+int_as_integer_ratio_impl(PyObject *self)
+/*[clinic end generated code: output=e60803ae1cc8621a input=c1aea0aa6fb85c28]*/
+{
+    return PyTuple_Pack(2, self, _PyLong_One);


True.as_integer_ratio() will return (True, 1). It should return (1, 1).

Hmm; good point. There's a precedent here in the form of True.numerator, which returns 1.

serhiy-storchaka · 2018-08-25T15:06:32Z

Objects/longobject.c

+Return a pair of integers, whose ratio is exactly equal to the original int
+and with a positive denominator.
+
+>>> (10).as_integer_ratio()


Do we need so much examples in a docstring?

I think it's useful to have at least one positive and one negative example, so that it's obvious at a glance that the behaviour for negatives is to give (for example) (-5, 1) rather than (5, -1). I could imagine users thinking that 0 was somehow a special case, too, so I like that we have the 0 example there.

serhiy-storchaka · 2018-08-25T15:07:56Z

Lib/test/test_long.py

                self.assertEqual(type(value >> shift), int)

+    def test_as_integer_ratio(self):
+        tests = [10, 0, -10, 1, 3]


Why so much similar cases are needed?

Add tests for booleans and other int subclasses. Check types of numerator and denominator.

serhiy-storchaka · 2018-08-25T15:10:24Z

Doc/library/stdtypes.rst

+
+   Return a pair of integers whose ratio is exactly equal to the original
+   integer and with a positive denominator. The integer ratio of integers
+   (whole numbers) is always the integer as the numerator and 1 as the


mdickinson

Changing my approval due to the issues Serhiy noted. @lisroach do you want to tackle the outstanding comments? I'm happy to pick this up if not.

bedevere-bot · 2018-08-25T16:43:54Z

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 I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

…iss_33073

lisroach · 2018-09-10T20:00:46Z

I have made the requested changes; please review again.

I am not sure if I could do the boolean check better- somehow in one line? I'm open to advice!

Thanks for all the reviews @mdickinson and @serhiy-storchaka it's been really helpful!

lisroach · 2018-09-13T20:14:19Z

@eric-wieser I believe Serhiy's thinking is correct, it should be (1, 1).
Subclasses of int inherit the same operations of int, and those operations create instances of int (as opposed to creating an instance of the subclass). For example, if we look at the unary plus of int:

>>> class Int(int):
...     pass
...
>>> x = Int(42)
>>> type(+x)
<class 'int'>
>>> type(+True)
<class 'int'>

rhettinger · 2018-09-13T23:18:58Z

Lib/test/test_long.py

+        class Foo(enum.IntEnum):
+            X = 42
+        self.assertEqual(Foo.X.as_integer_ratio(), (42, 1))
+        assert(type(Foo.X.as_integer_ratio()[0] == int))


This should be: self.assertEqual(type(Foo.X.as_integer_ratio()[0], int). Unittest doesn't use assertion statements.

rhettinger · 2018-09-13T23:21:41Z

Objects/longobject.c

+    return PyTuple_Pack(2, self, _PyLong_One);
+  else {
+      PyObject *temp = PyNumber_Positive(self);
+      Py_DECREF(temp);


The DECREF needs to occur after building the tuple; otherwise, the Python integer object can (and likely will) disappear before it gets used.

rhettinger · 2018-09-13T23:37:00Z

Objects/longobject.c

+  if PyLong_CheckExact(self)
+    return PyTuple_Pack(2, self, _PyLong_One);
+  else {
+      PyObject *temp = PyNumber_Positive(self);


We need another way to do this. The intent of this code is to construct a regular integer instance from an instance of an int subclass. The problem with PyNumber_Positive() is that the subclass can itself define pos() to return something other than an exact int. Elsewhere, we use _PyLong_Copy for this purpose.

Is there a reason why PyNumber_Index does not call _PyLong_Copy?

bedevere-bot · 2018-09-13T23:37:08Z

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 I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

Am checking to see the Serhiy's issues are resolved.

eric-wieser · 2018-09-14T06:16:37Z

Reviving a comment hidden away above - should operator.index / PyNumber_Index / int->tp_as_number->nb_index call _PyLong_Copy too for consistency?

sir-sigurd · 2018-09-14T06:21:43Z

Objects/longobject.c

+{
+    if PyLong_CheckExact(self) {
+        return PyTuple_Pack(2, self, _PyLong_One);
+    } else {


else { should be on the next line per PEP 7.

Missing parens on the if too

Objects/longobject.c

eric-wieser · 2018-09-14T07:12:39Z

ISTM, the code is reasonable as-is.

Despite the missing null check and invalid C syntax that works only because of a macro?

rhettinger · 2018-09-14T07:23:02Z

Eric, I didn't see your comments prior to merging. See PR 9297 for the cleanup. The part that was fine as-is was using PyTuple_Pack() on two different code paths.

eric-wieser · 2018-09-14T07:27:51Z

Agreed, the two code paths thing was unimportant. #9297 seems to address all my comments, other than the question about nb_index, which is tangential anyway

rhettinger · 2018-09-14T07:39:08Z

Can you note your review on 9297 please.

eric-wieser · 2018-09-14T07:40:31Z

If that's aimed at me, I don't know what you're asking me to do.

serhiy-storchaka

This PR was merged too soon. There are several issues with it. See also comments by @sir-sigurd and @eric-wieser.

serhiy-storchaka · 2018-09-14T08:32:08Z

Lib/test/test_long.py

        self.assertEqual(False.as_integer_ratio(), (0, 1))
-        assert(type(True.as_integer_ratio()[0]) == int)
-        assert(type(False.as_integer_ratio()[0]) == int)
+        self.assertEqual(type(True.as_integer_ratio()[0]), int)


Test also the denumerator type.

serhiy-storchaka · 2018-09-14T08:33:23Z

Objects/longobject.c

+    if PyLong_CheckExact(self) {
+        return PyTuple_Pack(2, self, _PyLong_One);
+    } else {
+        PyObject *numerator = _PyLong_Copy(self);


Use the same same code as for for the numerator getter.

Test the result for NULL.

serhiy-storchaka · 2018-09-14T08:37:14Z

Doc/whatsnew/3.8.rst

  was lifted.
  (Contributed by Serhiy Storchaka in :issue:`32489`.)

+* The ``int`` type now has a new ``as_integer_ratio`` method compatible


Add links:

:class:`int` :meth:`~int.as_integer_ratio` :meth:`float.as_integer_ratio`

serhiy-storchaka · 2018-09-14T08:48:08Z

Reviving a comment hidden away above - should operator.index / PyNumber_Index / int->tp_as_number->nb_index call _PyLong_Copy too for consistency?

This is a different issue. And I think that it should not.

bpo:33073 adding as_integer_ratio to ints.

ff0790e

the-knights-who-say-ni added the CLA signed label Aug 12, 2018

bedevere-bot added the awaiting review label Aug 12, 2018

pablogsal reviewed Aug 13, 2018

View reviewed changes

eric-wieser reviewed Aug 13, 2018

View reviewed changes

ZackerySpytz reviewed Aug 14, 2018

View reviewed changes

Updates as_integer_ratio to be one line.

d1daadc

mdickinson reviewed Aug 17, 2018

View reviewed changes

lisroach and others added 2 commits August 22, 2018 16:58

Adds ;, fixes spacing.

3b89b6f

Update test_doctest expected output to include builtins.int.as_intege…

48c7dd0

…r_ratio.

mdickinson added 3 commits August 25, 2018 12:52

Regenerate clinic files.

4ca566a

Rewrap text to keep within the line length limit.

2336cb4

One more test_doctest fix.

673a0ca

mdickinson approved these changes Aug 25, 2018

View reviewed changes

bedevere-bot added awaiting merge and removed awaiting review labels Aug 25, 2018

mdickinson added 2 commits August 25, 2018 13:58

Add 'what's new' entry.

5102589

Add Misc/ACKS entry.

a935a7b

mdickinson added the type-feature A feature request or enhancement label Aug 25, 2018

serhiy-storchaka reviewed Aug 25, 2018

View reviewed changes

mdickinson previously requested changes Aug 25, 2018

View reviewed changes

bedevere-bot removed the awaiting merge label Aug 25, 2018

bedevere-bot added the awaiting changes label Aug 25, 2018

eric-wieser mentioned this pull request Aug 25, 2018

ENH: Implement np.floating.as_integer_ratio numpy/numpy#10741

Merged

lisroach added 2 commits September 10, 2018 11:58

Adds boolean support.

3cd076c

Merge branch 'iss_33073' of https://github.com/lisroach/cpython into …

028417a

…iss_33073

lisroach added 3 commits September 13, 2018 13:26

Handles subclasses more smoothly. Adds unit tests.

2028d97

Fixes docstring and doc format.

89a0d9d

Regenerates argument clinic.

148225c

rhettinger requested changes Sep 13, 2018

View reviewed changes

bedevere-bot added awaiting changes and removed awaiting change review labels Sep 13, 2018

Move whatsnew entry to resolve a merge conflict

ac0f11f

rhettinger and others added 2 commits September 13, 2018 22:42

Restored bogus whitespace redaction

cb9c978

Updates the function call. Fixes tests.

d311b83

rhettinger approved these changes Sep 14, 2018

View reviewed changes

bedevere-bot added awaiting merge and removed awaiting changes labels Sep 14, 2018

Fixing failing Travis build.

d3ef843

sir-sigurd reviewed Sep 14, 2018

View reviewed changes

eric-wieser reviewed Sep 14, 2018

View reviewed changes

Objects/longobject.c Show resolved Hide resolved

eric-wieser reviewed Sep 14, 2018

View reviewed changes

Objects/longobject.c Show resolved Hide resolved

rhettinger merged commit 5ac7043 into python:master Sep 14, 2018

bedevere-bot removed the awaiting merge label Sep 14, 2018

serhiy-storchaka reviewed Sep 14, 2018

View reviewed changes

skirpichev mentioned this pull request Feb 12, 2023

gh-101825: mention, that as_integer_ratio() output is normalized #101843

Merged

Uh oh!

bpo-33073: Adding as_integer_ratio to ints. #8750

bpo-33073: Adding as_integer_ratio to ints. #8750

Uh oh!

Conversation

lisroach commented Aug 12, 2018 • edited by bedevere-bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pablogsal Aug 14, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mdickinson commented Aug 25, 2018

Uh oh!

mdickinson left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mdickinson left a comment

Choose a reason for hiding this comment

Uh oh!

bedevere-bot commented Aug 25, 2018

Uh oh!

lisroach commented Sep 10, 2018

Uh oh!

lisroach commented Sep 13, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bedevere-bot commented Sep 13, 2018

Uh oh!

eric-wieser commented Sep 14, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

eric-wieser commented Sep 14, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rhettinger commented Sep 14, 2018

Uh oh!

eric-wieser commented Sep 14, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lisroach commented Aug 12, 2018 •

edited by bedevere-bot

Loading

pablogsal Aug 14, 2018 •

edited

Loading

eric-wieser commented Sep 14, 2018 •

edited

Loading

eric-wieser commented Sep 14, 2018 •

edited

Loading