[Python-Dev] Issue 14417: consequences of new dict runtime error (original) (raw)

R. David Murray rdmurray at bitdance.com
Sat Mar 31 19:45:33 CEST 2012

On Sun, 01 Apr 2012 03:03:13 +1000, Nick Coghlan <ncoghlan at gmail.com> wrote:

On Sun, Apr 1, 2012 at 2:09 AM, Guido van Rossum <guido at python.org> wrote: > Here's a different puzzle. Has anyone written a demo yet that provokes > this RuntimeError, without cheating? (Cheating would be to mutate the > dict from inside the eq or hash method.) If you're serious > about revisiting this, I'd like to see at least one example of a > program that is broken by the change. Otherwise I think the status quo > in the 3.3 repo should prevail -- I don't want to be stymied by > superstition.

I attached an attempt to deliberately break the new behaviour to the tracker issue. It isn't actually breaking for me, so I'd like other folks to look at it to see if I missed something in my implementation, of if it's just genuinely that hard to induce the necessary bad timing of a preemptive thread switch.

Thanks, Nick. It looks reasonable to me, but I've only given it a quick look so far (I'll try to think about it more deeply later today).

If it is indeed hard to provoke, then I'm fine with leaving the RuntimeError as a signal that the application needs to add some locking. My concern was that we'd have working production code that would start breaking. If it takes a lot of threads or a lot of mutation to trigger it, then it is going to be a lot less likely to happen anyway, since such programs are going to be much more careful about locking anyway.

--David

More information about the Python-Dev mailing list