Brad Miller <[EMAIL PROTECTED]> added the comment: Thanks for all of the help. Using range_item certainly simplified my job. Although I more than made up for it with all of the decref and error checking calls.
One side effect of using range_item is that str(range(...)) is now subject to the same errors as indexing into really big range: for example: x = range(1000000000000000000) x[1] File "<stdin>", line 1, in <module> OverflowError: Python int too large to convert to C ssize_t 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. I also discovered that range_item does not work with negative indices. 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? I have attached a new patch for rangeobject.c Brad Added file: http://bugs.python.org/file10003/range_str_2.patch __________________________________ 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
