Range accepts arguments coerce-able into ints via __int__, but rejects
arguments coerce-able into longs but to large to fit into an int. 

The problem is in handle_range_longs in bltinmodule.c:1527-1541. If they
type is not an int or long, it should try to make it so before failing
(for consistency with smaller values at least). 

Attached is a file that reproduces this bug.

Is this a bug?
  print range(MyInt(2**64), MyInt(2**64+10)) 
produced
 TypeError: range() integer start argument expected, got instance.

print range(int(MyInt(2**64)), int(MyInt(2**64+10)))
should work.

Yes, that is a workaround, but 

range(MyInt(n), MyInt(n+10))

should work for any valid value of n, not just some of them.

FWIW, using xrange() it seems to give the proper error message:

Traceback (most recent call last):
  File "bad_range.py", line 12, in <module>
    print xrange(MyInt(2**64), MyInt(2**64+10))
OverflowError: long int too large to convert to int

Yes, the error for xrange is more illustrative of the problem, but just
shows that xrange has this a too. Why should xrange be invalid for
non-word sized values (especially as range works)? Incidentally, just a
week ago I had to write my own iterator for a project because xrange
couldn't handle large values.

According to the documentation
(http://docs.python.org/dev/library/functions.html) "The arguments must
be plain integers", so I think the wrong thing here is to run the
object's __int__() under the range()'s hood. I think the right thing to
do would be to explicitly invoke int() on passing an non-int argument as
parameter.

This is related to issue1540617 and issue1546078.

issue1540617 contains a simple patch that extend acceptable range of 
argument to +/-2**63

issue1546078 contains a complete long integer support implementation and  
was accepted in Py3k.

It looks like all three issues can be closed by either accepting or 
rejecting issue1540617 patch for 2.6 and marking issue1546078 patch as 
accepted for Py3k.

I'm -10 on the patch in issue1540617 ( +/-2**63).

Reason: It's a good thing that the range of "range" is limited since it
returns a list of integers. range(2**32) allocates (2**32)*16 bytes +
small overhead for ints plus the space for the list (probably
(2**32)*sizeof(ptr) which is 4 or 8 bytes). So far the memory for the
ints is *never* returned to the system. I'm working on the problem.

Christian,

I was probably a bit sloppy using "range" instead of "xrange," but issue1540617 is limited to xrange only.  Are you still -10 on extending 
xrange on 64-bit platforms to +/- 2**63?  If so, what is your position 
on backporting py3k's unlimited range implementation?

> So far the memory for the ints is *never* returned
> to the system. I'm working on the problem.

Christian,

Are you working on the memory problem or on this issue? I think I have a 
solution to OP's problem, but don't want to duplicate your effort.

I'm working on the memory problem. See #2039 and #2013.

xrange is a totally different story. I'm +0 on changing xrange. Is
Python 3.0's range function compatible with xrange? If the answer is
yes, we may reuse the code for an unlimited xrange.

Attached patch addresses OP's issue:

$ ./python.exe bad_range.py
[8, 9, 10, 11, 12, 13, 14, 15, 16, 17]
here
[18446744073709551616L, 18446744073709551617L, 18446744073709551618L, 
18446744073709551619L, 18446744073709551620L, 18446744073709551621L, 
18446744073709551622L, 18446744073709551623L, 18446744073709551624L, 
18446744073709551625L]
[18446744073709551616L, 18446744073709551617L, 18446744073709551618L, 
18446744073709551619L, 18446744073709551620L, 18446744073709551621L, 
18446744073709551622L, 18446744073709551623L, 18446744073709551624L, 
18446744073709551625L]

The only existing test that fails is range(1e100, 1e101, 1e101) 
producing a TypeError. It will now produce

>>> range(1e100, 1e101, 1e101)
__main__:1: DeprecationWarning: integer argument expected, got float
[10000000000000000159028911097599180468360808563945281389781327557747838
772170381060813469985856815104L]

Note that range(1e100, 1e101) would still fail:
>>> range(1e100, 1e101)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: range() result has too many items

An alternative solution would be to disallow non-ints regardless of 
their value, but that is more likely to break someone's code.

Alexander Belopolsky's patch looks like the right fix for range() to me. 

The xrange limits still hold, but that should probably be a separate
issue/ticket.

I'm just curious to know which is the right behavior.

# Python 3.0
Traceback (most recent call last):
  File "bad_range.py", line 7, in <module>
    print(range(MyInt(2**3), MyInt(2**3+10)))
TypeError: 'MyInt' object cannot be interpreted as an integer

# Python 2.7a0
[8, 9, 10, 11, 12, 13, 14, 15, 16, 17]
here
[18446744073709551616L, 18446744073709551617L, 18446744073709551618L,
18446744073709551619L, 18446744073709551620L, 18446744073709551621L,
18446744073709551622L, 18446744073709551623L, 18446744073709551624L,
18446744073709551625L]
Traceback (most recent call last):
  File "bad_range.py", line 11, in <module>
    print(range(MyInt(2**64), MyInt(2**64+10)))
TypeError: range() integer start argument expected, got instance.

I think *both* behaviors are wrong, the 3.0 one is backwards
incompatible, and the 2.7 one is inconsistent (accepting MyInt if it's <
32 bits, rejecting it for > 64 bits). 

For our particular use case, it is very annoying to not be able to use
non-ints. It goes against the principle duck typing by simply defining
the __int__ and __index__ methods.

Updating versions.

This change is out of scope for 2.5.3 (plus, the desired behavior still
seems to be debated)