I was wondering what would happen, so I tried this out for the heck of
it with:

Python 3.0a2 (py3k:59572M, Dec 19 2007, 15:54:07) [MSC v.1500 32 bit
(Intel)]
on win32

class a(int):
   def __new__(cls,number):
     return int.__new__(cls,number)
for x in range(0,a(5)):
  print(x)


This resulted in a:
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "a.py", line 5, in <module>
     for x in range(0,a(5)):
SystemError: ..\Objects\longobject.c:400: bad argument to internal
function
[41030 refs]

It looks like the rangeobject performs a FitsInLong test on each of
the parameters to range, which uses the function
_PyLong_FitsInLong(PyObject *vv) within longobject.c.  In tern, this
performs a typecheck:  #define PyLong_CheckExact(op) (Py_TYPE(op) ==
&PyLong_Type) that fails.

Martin, I'm asking you because according to svn blame I copied this from
the int/long integration branch last January.

I looked at the code of _PyLong_FitsInLong(), and I don't understand why
it wants an exact integer.  The code

        if (!PyLong_CheckExact(vv)) {
                PyErr_BadInternalCall();
                return 0;
        }

can just be omitted IMO, to make this problem go away.

There's no documentation for this function, and the only user
(rangeobject.c()) never checks for an error...

As of r59585, _PyLong_FitsInLong() is no longer.