On Sat, Mar 31, 2012 at 7:45 PM, R. David Murray <span dir="ltr">&lt;<a href="mailto:rdmurray@bitdance.com">rdmurray@bitdance.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">On Sun, 01 Apr 2012 03:03:13 +1000, Nick Coghlan &lt;<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>&gt; wrote:<br>
&gt; On Sun, Apr 1, 2012 at 2:09 AM, Guido van Rossum &lt;<a href="mailto:guido@python.org">guido@python.org</a>&gt; wrote:<br>
&gt; &gt; Here&#39;s a different puzzle. Has anyone written a demo yet that provokes<br>
&gt; &gt; this RuntimeError, without cheating? (Cheating would be to mutate the<br>
&gt; &gt; dict from *inside* the __eq__ or __hash__ method.) If you&#39;re serious<br>
&gt; &gt; about revisiting this, I&#39;d like to see at least one example of a<br>
&gt; &gt; program that is broken by the change. Otherwise I think the status quo<br>
&gt; &gt; in the 3.3 repo should prevail -- I don&#39;t want to be stymied by<br>
&gt; &gt; superstition.<br>
&gt;<br>
&gt; I attached an attempt to *deliberately* break the new behaviour to the<br>
&gt; tracker issue. It isn&#39;t actually breaking for me, so I&#39;d like other<br>
&gt; folks to look at it to see if I missed something in my implementation,<br>
&gt; of if it&#39;s just genuinely that hard to induce the necessary bad timing<br>
&gt; of a preemptive thread switch.<br>
<br>
</div>Thanks, Nick.  It looks reasonable to me, but I&#39;ve only given it a quick<br>
look so far (I&#39;ll try to think about it more deeply later today).<br>
<br>
If it is indeed hard to provoke, then I&#39;m fine with leaving the<br>
RuntimeError as a signal that the application needs to add some locking.<br>
My concern was that we&#39;d have working production code that would start<br>
breaking.  If it takes a *lot* of threads or a *lot* of mutation to<br>
trigger it, then it is going to be a lot less likely to happen anyway,<br>
since such programs are going to be much more careful about locking<br>
anyway.<br>
<font color="#888888"><br>
--David<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-dev" target="_blank">http://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="http://mail.python.org/mailman/options/python-dev/fijall%40gmail.com" target="_blank">http://mail.python.org/mailman/options/python-dev/fijall%40gmail.com</a><br>
</div></div></blockquote></div><br><div>Hm</div><div><br></div><div>I might be missing something, but if you have multiple threads accessing a dict, already this program: <a href="http://paste.pocoo.org/show/575776/">http://paste.pocoo.org/show/575776/</a> raises RuntimeError. You&#39;ll get slightly more obscure cases than changing a size raise RuntimeError during iteration under PyPy. As far as I understood, if you&#39;re mutating while iterating, you *can* get a runtime error.</div>

<div><br></div><div>This does not even have a custom __eq__ or __hash__. Are you never iterating over dicts?</div><div><br></div><div>Cheers,</div><div>fijal</div>