[Python-Dev] Issue 19332: Guard against changing dict during iteration

Eric Snow ericsnowcurrently at gmail.com
Wed Nov 6 20:12:38 CET 2013

On Wed, Nov 6, 2013 at 11:02 AM, Serhiy Storchaka <storchaka at gmail.com> wrote:
> Actually we should guard not against changing dict during iteration, but
> against iterating modifying dict (and only such modifications which change
> dict's keys).

s/iterating modifying/iteration modifying/ ?

Just to clarify, do you mean we should only guard against
modifications to the dict's keys during its iterator's __next__()?
Changes to the values during __next__() would be okay, as would
changes to the keys if they happen outside __next__()?

Presumably the above restriction also applies to the iterators of the
dict's views.

<chain of assumptions>

OrderedDict would also need to be changed, meaning this counter would
have to be accessible to and incrementable by subclasses.  OrderedDict
makes use of the MappingView classes in collections.abc, so those
would also have be adjusted to check this counter.

Would MutableMapping also need to be adjusted to accommodate the
counter?  Given that the MappingView classes would rely on the
counter, I'd expect MutableMapping to need some method or variable
that the views can rely on.  How would we make sure custom methods,
particularly __setitem__() and __delitem__(), increment the counter?

</chain of assumptions>

> For this we need only keys modification counter in a dict

A strictly monotonic counter, right?  Every mutation method of dict
would have to increment this counter.  So would that put a limit
(albeit a high one) on the number of mutations that can be made to a
dict?  Would there be conditions under which we'd reset the counter?
If so, how would existing iterators cope?

> and
> it's copy in an iterator (this doesn't increase memory requirements
> however).

Because the iterators (and views) already have a pointer to the dict, right?


More information about the Python-Dev mailing list