> In a world where ints and long ints have been unified the existence of 
> this error seems like a bug.
> 
> I think the right thing would be to fix range_item and range_length so 
> they do not use Py_ssize_t for the length of the range.  But I may be in 
> over my head on that guess.

The question is: what C type to use instead? Whatever native type you
use, it will always have a limitation. Assuming that range() elements
are typically used as indices into collections, having them Py_ssize_t
is fine because no standard collection (string, tuple, list) can have
more than 2**(8*sizeof(Py_ssize_t)) elements, on any computer, as
that would exceed the address space of that computer.

In any case, I think it is fine that str() has this limitation when
you can't actually access the values of the range object, anyway.
If the limit where to be removed, somebody would have to rewrite

> I have been poking around the tests and added some simple tests to the 
> test_range.py class as well.  I assume I should submit a patch for that 
> as well?

Indeed. The code looks fine to me now, please to provide a patch also.