On 8/23/06, alex.martelli <python-checkins@python.org> wrote:

--- python/trunk/Objects/floatobject.c  (original)
+++ python/trunk/Objects/floatobject.c  Wed Aug 23 22:42:02 2006
@@ -821,12 +821,12 @@
        ix = pow(iv, iw);
        PyFPE_END_PROTECT(ix)
        Py_ADJUST_ERANGE1(ix);
-       if (errno != 0) {
+        /* we need to ignore ERANGE here and just return inf */
+       if (errno != 0 && errno != ERANGE) {
                /* We don't expect any errno value other than ERANGE, but
                 * the range of libm bugs appears unbounded.
                 */
-               PyErr_SetFromErrno(errno == ERANGE ? PyExc_OverflowError :
-                                                    PyExc_ValueError);
+               PyErr_SetFromErrno(PyExc_ValueError);
                return NULL;

I don't think this can be right. The returnvalue of pow() in the case of ERANGE isn't defined anywhere that I can find, at least. How can we assume it is +Infinity? As I tried to say over the visiphone, you can't even use compile-time or startup-time checks for the behaviour because 'undefined' also means it need not be consistent, either. The best we could do, if we really wanted to return +inf instead of raising OverflowError (which I don't, but don't really care about either), is generate +Infinity in some guaranteed way. I'm sure Tim can come up with a convenient, portable way < 0.9 wink>.

But I'd prefer to keep it the way it was: x*x and x**2 don't always do the same thing. Floats have a lot more confusing features like that, such as 10*x - 9*x need not be x. I don't see the added value of trying to make it consistent in just this case, even if it's portable.