<p dir="ltr"><br>
On 6 Nov 2013 15:02, "Ethan Furman" <<a href="mailto:ethan@stoneleaf.us">ethan@stoneleaf.us</a>> wrote:<br>
><br>
> <a href="http://bugs.python.org/issue19332">http://bugs.python.org/issue19332</a><br>
><br>
> Summary:<br>
><br>
> --> d = {1: 'one'}<br>
> --> for k in d:<br>
> ...   d[k+1] = d[k] * k<br>
> ...<br>
> Traceback (most recent call last):<br>
>   File "<stdin>", line 1, in <module><br>
> RuntimeError: dictionary changed size during iteration<br>
><br>
> --> for k in d:<br>
> ...   del d[k]<br>
> ...<br>
> Traceback (most recent call last):<br>
>   File "<stdin>", line 1, in <module><br>
> RuntimeError: dictionary changed size during iteration<br>
><br>
><br>
> While the above two cases are covered, the following is not:<br>
><br>
> --> d = dict.fromkeys('abcd')<br>
> --> for i in d:<br>
> ...     print(i)<br>
> ...     d[i + 'x'] = None<br>
> ...     del d[i]<br>
> ...<br>
> d<br>
> a<br>
> dx<br>
> dxx<br>
> ax<br>
> c<br>
> b<br>
><br>
> Which can yield pretty bizarre results and does not raise an exception.<br>
><br>
> There is a patch to fix this.<br>
><br>
> Raymond's first comment was:<br>
><br>
> "The decision to not monitor adding or removing keys was intentional.  It is just not worth the cost in either time or space."<br>
><br>
> Considering that the first two scenarios do raise exceptions that statement does not seem correct, at least not with current code.<br>
><br>
> Later, Raymend rejected the patch with the comment:<br>
><br>
> "I disagree with adding such unimportant code to the critical path."<br>
><br>
> I understand we need to keep the critical path as fast as possible, and that it is a balancing act between completely correct code and warnings in the docs.<br>
><br>
> What I'm hoping for is either someone to shed some light on what is the "unimportant" part,</p>
<p dir="ltr">The behaviour of mutating builtin containers while iterating over them is formally undefined beyond "it won't segfault" (one of the few such undefined behaviours in Python). The associated exceptions are thus strictly "best effort given other constraints".</p>

<p dir="ltr">Since most loops are unlikely to add and remove exactly balanced numbers of keys, and dict read and write performance impacts essentially all Python code except that which only operates on function locals, only checking for size changes between iteration steps is a nice way to get 99% of the benefits without paying any of the costs.</p>

<p dir="ltr">>or perhaps some performance measurements that would show there is no performance based reason to not have the patch added.  (I can try to do the performance part myself if necessary, I'm just not sure what all the steps are yet.)</p>

<p dir="ltr">If the benchmark suite indicates there's no measurable speed penalty then such a patch may be worth reconsidering. I'd be astonished if that was actually the case, though - the lowest impact approach I can think of is to check for live iterators when setting a dict entry, and that still has non-trivial size and speed implications.</p>

<p dir="ltr">Cheers,<br>
Nick.<br></p>
<p dir="ltr">><br>
> --<br>
> ~Ethan~<br>
> _______________________________________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-dev">https://mail.python.org/mailman/listinfo/python-dev</a><br>
> Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com">https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com</a><br>
</p>