# I support PEP 326

Josiah Carlson jcarlson at nospam.uci.edu
Fri Jan 23 04:25:16 CET 2004

```> Or, expressing the idea that they're the ends of a number line:
>
> PosInf, NegInf
> PosInfinity, NegInfinity
> PositiveInfinity, NegativeInfinity
>
> If IEEE floating point was done correctly everywhere, I'd say make
> them the corresponding floating-point constants (Inf+ and Inf-).
>
> Or,
> FreakingHuge, FreakingHugeTheOtherWay

PosInf, NegInf
PosInfinity, NegInfinity
PositiveInfinity, NegativeInfinity

All suggest that the Max and Min (or whatever you want to call them) are
numbers.  Such a thing is misleading, and also tends to tie PEP 326 with
PEP 754 (IEEE 754 Floating Point Special Values, which makes the case
for a consistant name for +/- FP Infinity).

As stated in my PEP:

Guido has brought up [2]_ the fact that there exists two constants
that can be used in the interim for maximum values: sys.maxint and
floating point positive infinity (1e309 will evaluate to positive
infinity).  However, each has their drawbacks.

- On most architectures sys.maxint is arbitrarily small (2**31-1 or
2**63-1) and can be easily eclipsed by large 'long' integers or
floating point numbers.

- Comparing long integers larger than the largest floating point
number representable against any float will result in an exception
being raised::

>>> cmp(1.0, 10**309)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
OverflowError: long int too large to convert to float

Even when large integers are compared against positive infinity::

>>> cmp(1e309, 10**309)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
OverflowError: long int too large to convert to float

- These same drawbacks exist when numbers are small.

```