math.isfinite() can raise exception when called on a number

[tfish2]

BPO	47121
Nosy	@tim-one, @rhettinger, @mdickinson, @stevendaprano, @serhiy-storchaka, @nathanielmanistaatgoogle

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2022-03-25.17:28:43.481>
labels = ['3.11', 'type-feature', 'docs']
title = 'math.isfinite() can raise exception when called on a number'
updated_at = <Date 2022-04-08.10:09:13.165>
user = 'https://bugs.python.org/tfish2'

bugs.python.org fields:

activity = <Date 2022-04-08.10:09:13.165>
actor = 'tfish2'
assignee = 'docs@python'
closed = False
closed_date = None
closer = None
components = ['Documentation']
creation = <Date 2022-03-25.17:28:43.481>
creator = 'tfish2'
dependencies = []
files = []
hgrepos = []
issue_num = 47121
keywords = []
message_count = 8.0
messages = ['416010', '416011', '416018', '416040', '416840', '416842', '416843', '416969']
nosy_count = 8.0
nosy_names = ['tim.peters', 'rhettinger', 'mark.dickinson', 'steven.daprano', 'docs@python', 'serhiy.storchaka', 'Nathaniel Manista', 'tfish2']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue47121'
versions = ['Python 3.11']

[tfish2]

>>> help(math.isfinite)
isfinite(x, /)
    Return True if x is neither an infinity nor a NaN, and False otherwise.

So, one would expect the following expression to return True or False. We instead observe:

>>> math.isfinite(10**1000)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: int too large to convert to float

(There likewise is a corresponding issue with other, similar, functions).

This especially hurts since PEP-484 states that having a Sequence[float] xs does not allow us to infer that all(issubclass(type(x), float) for x in xs) actually holds - since a PEP-484 "float" actually does also include "int" (and still, issubclass(int, float) == False).

Now, strictly speaking, help(math) states that

DESCRIPTION
This module provides access to the mathematical functions
defined by the C standard.

...but according to "man 3 isfinite", the math.h "isfinite" is a macro and not a function - and the man page does not show type information for that reason.

[rhettinger]

The math.isfinite() docs could be changed to something like, "coerces x to a float if possible and then returns True if x is neither an infinity nor a NaN, and False otherwise." Or there could be a general note about which functions (most of them) coerce to float (which can fail).

With respect to typing and PEP-484, I don't see a bug or documentation issue. Types relationships are useful for verifying which methods are available, but they don't make promises about the range of valid values. For example math.sqrt(float) -> float promises which types are acceptable but doesn't promise that negative inputs won't raise an exception. Likewise, "n: int=10; len(range(n))" is type correct but will raise an OverflowError for "n = 10**100".

[tfish2]

The problem with PEP-484 is that if one wants to use static type analysis, neither of these options are good:

• Use static annotations on functions, and additionally spec
  out expectations in docstrings. Do note that the two types places
  where "float" is mentioned here refer to different concepts.
  This looks as if there were duplication, but there actually
  isn't, since the claims are different. This is confusing as hell.

def foo(x: float) -> float:
  """Foos the barbaz

Args:
x: float, the foobar
Returns:
float, the foofoo"""

The floats in the docstring give me a guarantee: "If I feed in a float, I am guaranteed to receive back a float". The floats in the static type annotation merely say "yeah, can be float or int, and I'd call it ok in these cases" - that's a very different statement.

• Just go with static annotations, drop mention of types
  from docstrings, and accept that we lose the ability to
  stringently reason about the behavior of code.

With respect to this latter option, I think we can wait for "losing the ability to stringently reason about the behavior of code" to cause major security headaches. That's basically opening up the door to many problems at the level of "I can crash the webserver by requesting the url http://lpt1".

[serhiy-storchaka]

Most (but not all) functions in the math module implicitly convert its arguments to float. Here we can get an OverflowError. Do we want to add a note to every function that does it? Or add a general note at the top of the file and add exclusion notes to functions which do not convert arguments to float?

BTW, there is a general note: "Except when explicitly
noted otherwise, all return values are floats."

[stevendaprano]

Isn't this just a quality of implementation issue?

math.isfinite should return True for all ints, since all ints are finite. (There are no int infinities or NANs). There is no need to coerce them to float to know that they are finite.

Likewise for Fractions. If they overflow, that could be caught and True returned.

Decimal infinities convert to float infinities, so the only way you can get an overflow error is if the Decimal is finite but too big to convert. So again, isfinite could (should?) catch the overflow error and return True.

Any numeric type that has an infinity which does not coerce to float infinity, but overflows instead, is buggy, and its not isfinite's responsibility to protect against that.

So here is my suggestion:

isfinite() should return True for all ints, without needing to coerce them to float. For other numeric types, it should try to coerce them to float, and catch OverflowError and raise True. This should be documented, so that other numeric types know what contract they are required to follow (infinity coerces to float infinity).

I'm going to change this to an enhancement for 3.11 (or 3.12).

[rhettinger]

isfinite() should return True for all ints, without needing
to coerce them to float

Whoa there. You're venturing into changing what those math functions were all about and the core approach to how they operate.

A zigzag to this new direction would need discussion with all the math folks. Many tools in the math module are thin wrapper around libmath and we never intended to be universal handlers of all numeric types. We have a lot of functions that start by coercing their input to a float.

My two cents is that this would open an endless can of worms and make everyone pay a time and complexity cost for a feature that almost no one needs. AFAICT is more of a purity issue than an actual practical need that would warrant separate code paths (for example, we recently closed an issue where someone wanted math.log() to have a separate code path for Fraction inputs where it return log(f.numerator) - log(f.denominator) with the goal of handling fractional values smaller than float_min).

[tim-one]

I'll testify that I won't volunteer one second of my time pursuing these abstract "purity" crusades ;-) isfinite() et alia were added to supply functions defined by current standards to work on IEEE floating-point values. People working with floats have reasonable expectations that Python will supply workalikes for industry-stand float functions.

If was had to cater to all possible "numberish" types, we'd never add anything new again :-( Doing that in a principled way requires dedicated new dunder methods, and that's a high bar.

That I said, I extended math.log() decades ago to work on giant integers. It was useful for real projects I was working on at the time - I was scratching my own itches.