mutating a deque whilst iterating over it

[Dan Stromberg]

On Sat, Feb 13, 2021 at 10:25 AM duncan smith <duncan at invalid.invalid>
wrote:

> On 12/02/2021 03:04, Terry Reedy wrote:
> > On 2/11/2021 3:22 PM, duncan smith wrote:
> >
> >>        It seems that I can mutate a deque while iterating over it if I
> >> assign to an index, but not if I append to it. Is this the intended
> >> behaviour?
>
> What I was really wondering was whether the behaviour is as it is
> because of the implementation or because it's how deques should ideally
> behave. i.e. In my implementation do I stick strictly to the same API,
> or allow it to differ? In some places I'm jumping through hoops to stick
> to the API, and (when it comes to iteration) I'm jumping through
> different hoops for different types of container (e.g. lists versus
> deques). BTW, the reason I am implementing these at all is that my
> containers are on-disk. Cheers.
>
> collections.deque appears to take the approach of  "allow everything we
can based on our implementation, and trust the client not to overuse
features".

In fact, in Python, "over abstraction" is often seen as a bad thing, mostly
because it slows things down so much.

If you want something more abstracted, you might have a look at:
https://stromberg.dnsalias.org/~strombrg/linked-list/
https://pypi.org/project/linked_list_mod/

(Both URL's are about the same module)

Note that linked_list_mod is quite a bit slower than a collections.deque.
Deques use a clever-but-hidden trick to gain a lot of speed - it's really a
linked list of built in lists, which gives better locality of reference
that masks CPU caches very happy.  linked_list_mod goes for abstraction and
simplicity.