Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > 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. __________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2610> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
