Never mind, I got it. This always raised RuntimeError. I see this should be considered support in favor of keeping the change, since sharing dicts between threads without locking is already fraught with RuntimeErrors.
At the same time, has anyone looked at my small patch (added to the issue) that restores the retry loop without recursion? On Tue, Apr 3, 2012 at 3:17 PM, Guido van Rossum <gu...@python.org> wrote: > 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 <fij...@gmail.com> wrote: >> On Sat, Mar 31, 2012 at 7:45 PM, R. David Murray <rdmur...@bitdance.com> >> wrote: >>> >>> On Sun, 01 Apr 2012 03:03:13 +1000, Nick Coghlan <ncogh...@gmail.com> >>> wrote: >>> > On Sun, Apr 1, 2012 at 2:09 AM, Guido van Rossum <gu...@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@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) -- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
