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
The current algorithm for remove() rotates the deque one-by-one until a match is found, pops it off the deque and does single mass rotate to undo the 1-step rotates.
An alternative approach is to use deque_index() to locate the value of interest and use deque_del_item() to remove it.
If not value is found, the alternative is better because it never moves the data in the deque. If the value is found, the alternative removes it using two mass rotations. The advantage in that case is the mass rotates are faster than many 1-step rotates. The disadvantage is that we go through the pointer chain twice (the first time visiting and comparing every element and the second time only following the chain of links).
If the deque mutates during the search, a RuntimeError is raised. This is a behavior change, formerly it raised an IndexError.
Find not just an index in a deque, but a block and an index in a block. After that move left or right part of a deque one position right or left. __delitem__() could be 2 times faster, remove() could be faster too. Helpers proposed in bpo-17394 allow to do this easily.
Am closing this one because it isn't worth an API change. The remove() method is little used and to the extent people do use it, they expect it to work like list.remove(). The latter never raises a RuntimeError.