Steven D'Aprano added the comment: 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27975> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com