On Tue, Sep 06, 2016 at 05:59:08PM +0000, Mark Dickinson wrote:
> Why do you single out `int` for special treatment, 

Mostly as a demonstration for what could be done, not necessarily as 
what should be done. Secondly as a potential optimization. Why go to the 
expense of converting something to a float when there's a much 
cheaper(?) test?

> but not `Fraction` or `Decimal`?

They're not built-ins. They would have to be imported first, before you 
can test for their types. That could be costly, and it would rarely be 
necessary.

> How should the implementation handle Fraction objects, and why?

If some hypothetical subclass of Fraction provides a NAN or INF value, 
trust that float(x) of those values will return a float NAN or INF. If 
the conversion overflows, the value isn't a NAN or INF.

> How should the implementation handle a Fraction-like object 
> implemented by a user?

As above.

> Why only objects of exact type `int`, but not instances of subclasses?

Subclass of int might hypothetically implement their own NAN or INF 
values. In which case, trust that MyInt('nan').__float__() will return a 
NAN float as it is supposed to.

> Your suggestion replaces a straightforward 
> mental model (math.isnan converts its input to float, then operates on 
> it, just like almost all other math module functions) with something 
> more complicated.

Not more complicated. An even more simple *model*. The existing model 
for (let's say isnan):

"Convert the number x to a float, which may Overflow, then return 
whether the float is a NAN."

Versus the even simpler model:

"Return whether the number x is a NAN."

(Which of course hides a more complex *implementation*.)

Versus the practice of pushing the complexity onto the users:

"Oh gods, what sort of number is my x? If I pass it to math.isnan, will 
it blow up? Better wrap it in a try...except ValueError just in case. 
[Later] Ah, dammit, I meant OverflowError! Oh no, is there an 
UnderflowError for Fractions?"

I guess the argument boils down to whether we want to prioritise 
simplicity or usefulness in the math module.