[Python-Dev] Issue 14417: consequences of new dict runtime error

[Guido van Rossum]

Try reducing sys.setcheckinterval().

--Guido van Rossum (sent from Android phone)
On Mar 31, 2012 10:45 AM, "R. David Murray" <rdmurray at bitdance.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120331/1d087f4e/attachment.html>