Nick Coghlan added the comment: Nice! The one thing I would suggest double checking with this change is whether or not we have test cases covering ranges with lengths that don't fit into ssize_t. It's been years since I looked at that code, so I don't remember exactly how it currently works, but it does work (except for __len__, due to the signature of the C level length slot):
>>> bigrange = range(int(-10e30), int(10e30)) >>> len(bigrange) Traceback (most recent call last): File "<stdin>", line 1, in <module> OverflowError: Python int too large to convert to C ssize_t >>> bigrange[:] range(-9999999999999999635896294965248, 9999999999999999635896294965248) >>> bigrange[0:-1] range(-9999999999999999635896294965248, 9999999999999999635896294965247) >>> bigrange[::2] range(-9999999999999999635896294965248, 9999999999999999635896294965248, 2) >>> bigrange[0:-1:2] range(-9999999999999999635896294965248, 9999999999999999635896294965247, 2) ---------- nosy: +ncoghlan _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27867> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
