[Python-Dev] Issue 19332: Guard against changing dict during iteration (original) (raw)

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.

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?

-eric

More information about the Python-Dev mailing list