[Python-Dev] Issue 14417: consequences of new dict runtime error (original) (raw)
Guido van Rossum guido at python.org
Wed Apr 4 00:17:02 CEST 2012
- Previous message: [Python-Dev] Issue 14417: consequences of new dict runtime error
- Next message: [Python-Dev] Issue 14417: consequences of new dict runtime error
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
I'm confused. Are you saying that that program always raised RuntimeError, or that it started raising RuntimeError with the new behavior (3.3 alpha 2)?
On Tue, Apr 3, 2012 at 2:47 PM, Maciej Fijalkowski <fijall at gmail.com> wrote:
On Sat, Mar 31, 2012 at 7:45 PM, 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
Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fijall%40gmail.com
Hm I might be missing something, but if you have multiple threads accessing a dict, already this program: http://paste.pocoo.org/show/575776/ raises RuntimeError. You'll get slightly more obscure cases than changing a size raise RuntimeError during iteration under PyPy. As far as I understood, if you're mutating while iterating, you can get a runtime error. This does not even have a custom eq or hash. Are you never iterating over dicts? Cheers, fijal
-- --Guido van Rossum (python.org/~guido)
- Previous message: [Python-Dev] Issue 14417: consequences of new dict runtime error
- Next message: [Python-Dev] Issue 14417: consequences of new dict runtime error
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]