Allow `float("inf")` and `float("-inf")` in literals

[antonagestam]

I have been frequently using positive and negative infinity as default values for values that should otherwise be ints. Because of Python's duck typing this is a convenient pattern that sometimes allows reducing some special-casing logic.

def less_than(value: int, limit: int | None) -> bool:
    if limit is None:
        return True
    return value < limit

vs

def less_than(value: int, limit: int | Literal[float("inf")]) -> bool:
    return value < limit

Would it be feasible to special-case the expressions float("inf") and float("-inf") and make type-checkers regard them as literal values, even though they aren't strictly speaking language-level literals?

---

For posterity, PEP 586 mentions this with:

Representing Literals of infinity or NaN in a clean way is tricky; real-world APIs are unlikely to vary their behavior based on a float parameter.

So I guess what I'm asking here is: am I an odd duckling or could it be worth considering +/- infinity as legal values in literal types?

[srittau]

It makes sense to me to allow inf, -inf, and nan as literal values. After all, we allow all other float values as literal values as well.

[JelleZijlstra]

After all, we allow all other float values as literal values as well.

We don't. PEP 586 lists all valid types for literals, and float isn't among them.

[erictraut]

Yes, float literals are not supported.

Also, call expressions are not (nor should be) allowed in type annotations. It's important that we keep type annotation expressions simple — for reasons of consistency and evaluation performance.

[JelleZijlstra]

An approach that avoids call expressions could be to allow Literal[math.inf] (and Literal[math.nan]?). Type checkers would then have to special case math.inf as referring to float("inf").

Not sure this is worth changing in the type system though. In the OP's case, they could just write limit: int | float (or limit: float).

[Gobot1234]

I currently am designing an api which looks like:

def redirect_to(self, somewhere_else: Self, * for: timedelta | Literal[float("inf")]): ...

Because I want to make sure people don't have to deal with the units they are passing. Specifying this is in seconds I think at least is a bit annoying especially if the endpoint I'm calling changes it's units without warning.

[antonagestam]

@JelleZijlstra Just a nitpick but "they could just write limit: int | float", that wouldn't be equivalent as that wouldn't give a type error for less_than(1, 5.5) (I really only wanted to allow ints and infinity, not all floats).

@erictraut That makes sense, would it be less complex to do what Jelle suggests? Although I realize this feature would probably have a quite low "return on investment" in terms of gained typing accuracy per time invested in building and specifying it.

[Kyrixty]

My code has float("-inf") bugs 😎

[Avasam]

Just my 2 cents, I am no professional on the matter. Could inf, +inf, -inf and nan (with names that are actually usable as types) be type aliases of float? And special-cased by type checkers that supports them. Or maybe a new PEP needs to be suggested 🤷
ie:

NegativeInfinity: TypeAlias = float
PositiveInfinity: TypeAlias = float
Infinity: NegativeInfinity | PositiveInfinity
NotANumber: TypeAlias = float
# idk if this is even feasable, or even needed.
# Maybe it could be useful in some arithmetic cases, or when delaying.
# Reminds me of LiteralString for its safety applications.
FiniteFloat: TypeAlias = float 

float("-inf")  # type: NegativeInfinity  # type: Literal[NegativeInfinity]
float("+inf")  # type: PositiveInfinity  # type: Literal[PositiveInfinity]
float("inf")  # type: PositiveInfinity  # type: Literal[PositiveInfinity]
float("nan")  # type: NotANumber  # type: Literal[NotANumber]

I agree this is "low return on investment". Still something I would like as a type user.

[hauntsaninja]

For OP's use case, maybe a "comparable-to-int" protocol could work? This is probably a good type to choose for the pyyaml PR that got linked here

[antonagestam]

@hauntsaninja No that would not have worked, as already repeated, the real usecase really required int.

[HeWeMel]

Here is my use case for the same feature request:

I am the author of NoGraphs, a library dealing with implicit graphs. Here, the application can choose what data types to use (including rare choices like Decimal or arbitrary precision floats), optionally made type-safe by type annotations.

A common choice for graph applications is to use int for edge weights and distances. But just because an infinity value is needed as default, the annotation needs to be int | float (or just float). This is disturbing from the perspective of the application, because it uses int to exclude precision problems - and then, float occurs "everywhere" in the application...

(I hope, this can be helpful for the discussion - I am no specialist in the topic. I might be completely wrong...)