[issue27975] math.isnan(int) and math.isinf(int) should not raise OverflowError

Mark Dickinson added the comment: Closing this as "won't fix". I agree with Tim that the right way to handle this is to make math.isnan behave like math.floor and math.ceil currently do, via new special methods, but (1) I think introducing new special methods should probably be a PEP-level cha

[issue27975] math.isnan(int) and math.isinf(int) should not raise OverflowError

Mark Dickinson added the comment: > as would `math.isnan(Decimal('1e500'))` Whoops, no. I'd forgotten that large finite `Decimal` objects end up as `float` infinities under conversion. Not sure I like that much, but it is what it is ... -- ___ Pytho

[issue27975] math.isnan(int) and math.isinf(int) should not raise OverflowError

Mark Dickinson added the comment: [Steven] > Versus the even simpler model: > "Return whether the number x is a NAN." But what you're proposing doesn't match that description! Under your proposal, `math.isnan(10**1000)` would be `False`, but `math.isnan(Fraction(10**1000))` would again raise a

[issue27975] math.isnan(int) and math.isinf(int) should not raise OverflowError

Steven D'Aprano added the comment: On Tue, Sep 06, 2016 at 05:59:08PM +, 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

[issue27975] math.isnan(int) and math.isinf(int) should not raise OverflowError

Tim Peters added the comment: The only sane way to do things "like this" is to allow types to define their own special methods (like `__isnan__()`), in which case the math module defers to such methods when they exist. For example, this is how `math.ceil(Fraction)` works, by deferring to `Fra

[issue27975] math.isnan(int) and math.isinf(int) should not raise OverflowError

Mark Dickinson added the comment: > As a convenience for whom? I was referring to the general math module model. Being able to type `sqrt(2)` rather than having to type `sqrt(float(2))` or `sqrt(2.0)` is a convenience. -- ___ Python tracker

[issue27975] math.isnan(int) and math.isinf(int) should not raise OverflowError

Mark Dickinson added the comment: > It shouldn't be hard to do the equivalent of: Right, that's not hard at all. But is it what we *want* to do? Why do you single out `int` for special treatment, but not `Fraction` or `Decimal`? How should the implementation handle Fraction objects, and why? H

[issue27975] math.isnan(int) and math.isinf(int) should not raise OverflowError

Steven D'Aprano added the comment: As a convenience for whom? Certainly not the poor user, who thinks that math.isnan(x) should return False if the number x is not a NAN. Since neither 10**1 nor 10**10 are NANs, why should one return correctly and the other raise a completely spurious Over

[issue27975] math.isnan(int) and math.isinf(int) should not raise OverflowError

Mark Dickinson added the comment: Related: #18842 -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue27975] math.isnan(int) and math.isinf(int) should not raise OverflowError

Mark Dickinson added the comment: I see this as a documentation issue: the vast majority of math module functions are designed to operate on floats, and if given a non-float input, simply convert that input to a float as a convenience. If we start special-casing math module functions for int,

[issue27975] math.isnan(int) and math.isinf(int) should not raise OverflowError

New submission from Steven D'Aprano: Currently, math.isnan(n) and math.isinf(n) for n an int may raise OverflowError if n is too big to convert to a float, e.g.: py> math.isnan(10**1) Traceback (most recent call last): File "", line 1, in OverflowError: int too large to convert to float