You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
assignee=Noneclosed_at=<Date2019-10-29.03:30:28.840>created_at=<Date2019-10-29.03:03:16.796>labels= ['3.8', 'library']
title='small change at bisect_left function for easy understanding'updated_at=<Date2019-10-29.04:38:56.486>user='https://github.com/Windsooon'
bisect_left should be similar to bisect_right. However, the current implement didn't reflect it. A little bit update for the bisect_left function could make the user easy to understand their relation.
defbisect_left(a, x, lo=0, hi=None):
iflo<0:
raiseValueError('lo must be non-negative')
ifhiisNone:
hi=len(a)
whilelo<hi:
mid= (lo+hi)//2# <= should be the only difference between bisect_left and bisect_rightifx<=a[mid]: hi=midelse: lo=mid+1returnlo
So as far as possible, CPython only uses __lt__ ("<") element comparisons for its order-sensitive algorithms. This is documented for list.sort(), but the bisect and heapq modules strive to do the same.
The point is to minimize the number of comparison methods a new type needs to implement to participate (and "just one: __lt__" is ideal).
Your change would require they implement "__le__" too, so is unlikely to be accepted for CPython.
New changeset 3c88199 by Miss Skeleton (bot) (Raymond Hettinger) in branch 'master': bpo-38626: Add comment explaining why __lt__ is used. (GH-16978) 3c88199
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: