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.

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 changeset d998d87f0aa0 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.

See issue 28060 for fast path cleanup.