(original) (raw)

On Mar 31, 2012 10:45 AM, "R. David Murray" <rdmurray@bitdance.com> wrote:

On Sun, 01 Apr 2012 03:03:13 +1000, Nick Coghlan <ncoghlan@gmail.com> wrote:
> On Sun, Apr 1, 2012 at 2:09 AM, Guido van Rossum <guido@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