To me the doc strongly implies, but does not boldly and baldly say, that base should be an int.

"A base-n literal consists of the digits 0 to n-1, with a to z (or A to Z) having values 10 to 35. The default base is 10. The allowed values are 0 and 2-36. Base-2, -8, and -16 literals can be optionally prefixed with 0b/0B, 0o/0O, or 0x/0X, as with integer literals in code. Base 0 means to interpret exactly as a code literal, so that the actual base is 2, 8, 10, or 16, and so that int('010', 0) is not legal, while int('010') is, as well as int('010', 8)."

I think it should be revised to say "The allowed values are ints 0 and 2-36." (or 'integers' or 'index values'). If it had been that already, the current behavior would clearly be a bug and eligible to be fixed in 3.2/3. As it is, I will not argue with whatever others do.

(I strongly suspect there are other places in the docs where int args are similarly implied but not explicit, but int-ness *is* checked. If someone were to complain about 0.0 being rejected, I expect we would correct the doc, not the code.;-)