R. David Murray <rdmur...@bitdance.com> added the comment: Antoine: I don't think the point of this code is to come up with a unit (or other) test for the behavior, but to try to determine empirically whether or not this error is likely to be an issue in naive production code (whether it is existing 3.x code or stuff ported from Python2). Thus the mention of "cheating" (doing things production code would not be doing).
The answer so far appears to be "no", which is good. Which in the context of this particular issue then raises the question of whether there is in fact any additional support beyond the normal threading lock facilities that we want to provide in the stdlib. And the answer to that is thus probably no as well, since code likely to run into the error is also likely to need locking around the dict in question *anyway*. Which is what Guido's intuition was to begin with. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14417> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
