I support PEP 326

[Josiah Carlson]

> 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.