On Wed, Nov 6, 2013 at 11:02 AM, Serhiy Storchaka <storch...@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? -eric _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
