Seen on reddit [1]: >>> True % 10>>> True % 2TrueI believe that we should be returning an int in both these cases; this looks like a longobject.c fast path gone wrong.[1]https://www.reddit.com/r/learnpython/comments/4y5bh1/can_someone_explain_why_true_1_0_but_true_2_true/

Ah, it looks as though this is already fixed in master, and it's probably not worth fixing for 3.5. Closing.

Whoops; no, it's not fixed. 3.6 introduced a fast path that has the side-effect of fixing this issue for the `True % 2` case, but not for all cases:>>> False % 2False>>> True % 21>>> class MyInt(int): pass... >>> type(MyInt(0) % 6)<class '__main__.MyInt'>>>> type(MyInt(1) % 6)<class 'int'>

FWIW, I'd suggest not changing this in 3.5; only in 3.6. It's a fairly harmless bug that's been with us throughout the 3.x series so far (and even back into 2.x, if you start looking at behaviour with subclasses of `long`).

This can only happen because of a hole in the tests.  test_bool.BoolTest.test_math appears to test every binary int op, including bitwise, *except* %.After        self.assertIsNot(False/1, False)add        self.assertEqual(False%1, 0)        self.assertIsNot(False%1, False)  # currently fails        self.assertEqual(True%1, 1)        self.assertIsNot(True%1, True)test_int tests int() calls, not int math, so I don't know where the equivalent tests on int math with subclasses are or would go.

issue27792.patch tries to fix this.BTW, Mark, do you think the fast path in long_mod is really needed? Actually the same fast path has already existed in l_divmod.

Thanks for the patch. I think what we really want here is a call to `long_long` rather than `PyNumber_Long`; `PyNumber_Long` includes all the conversions using `__trunc__`, etc., which we don't need here.

> BTW, Mark, do you think the fast path in long_mod is really needed?I agree that the fast paths need looking at; it seems there's a fair bit of redundancy there. But not in this issue, please!

Oh, sorry. I forgot about long_long. Actually I did think for a while to search for a good function here. :( v2 uses long_long now.> I agree that the fast paths need looking at; it seems there's a fair bit of redundancy there. But not in this issue, please!Don't worry. It's only a passing mention. Not in this thread. :)

New changesetd998d87f0aa0 by Mark Dickinson in branch 'default':Issue#27792: force int return type for modulo operations involving bools.https://hg.python.org/cpython/rev/d998d87f0aa0

issue27792_v2.patch LGTM. Thanks for the fix!

Thanks for your work too. ;) You does the most important change.

> BTW, Mark, do you think the fast path in long_mod is really needed? Actually the same fast path has already existed in l_divmod.Seeissue 28060 for fast path cleanup.