New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bisect index out of bounds issue #66873
Comments
The precondition for all the bisect functions is implemented like this: if lo < 0:
raise ValueError('lo must be non-negative')
if hi is None:
hi = len(a) Now, of course, if hi is given, and hi >= 2 * len(a), then we get an IndexError. In case hi < 0, we always get 0 as a result (even if the element is there). I think it would be better to treat the hi in the precondition in the same way as the lo parameter: that means, raise a ValueError in case hi has an illegal value. Disclaimer: of course, it makes no sense to give an illegal argument to that function; still, since lo is treated against illegal values, maybe it's better to do the same for hi. At the same time, maybe moving the precondition code in a separate function (which raises a ValueError in case precondition is not met) makes more sense, for not repeating the same code in all bisect functions. A small snippet which reproduces this: from bisect import bisect_left
a = [1, 2, 3, 4]
idx = bisect_left(a, 2, 0, 10) # 10 > 2 * 4
print(idx) |
These functions are very old and the API is unlikely to change, particularly if the goal is to change one kind of exception to another (making bad inputs fail in a different way than they do now). As far as I can tell, the current arrangement has never been a actual problem in practice. |
Sure, it is your call. As said, this is rather an enhancement. Still, if I were to decide, I would chose:
That being said, from my point of view this ticket can be closed. |
Originally, there was no special test for lo. The test was added only because negative lo value failed in an unfortunate way (with an infinite loop). No change to hi was made because (it succeeded in some cases and existing code might be relying on that or it failed in clear-cut way by raising an IndexError).
I concur. When there isn't a clear case for change, it is usually better to favor stability over potential disruption. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: