Message273995
| Author |
ncoghlan |
| Recipients |
mark.dickinson, ncoghlan, serhiy.storchaka, tehybel, terry.reedy |
| Date |
2016年08月31日.04:06:34 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1472616394.87.0.838720636352.issue27867@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
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) |
|