Seen on reddit [1]:

>>> True % 1
0
>>> True % 2
True

I 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 % 2
False
>>> True % 2
1
>>> 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.

bpo-27792.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 changeset d998d87f0aa0 by Mark Dickinson in branch 'default':
Issue bpo-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.

See bpo-28060 for fast path cleanup.