Message157315
| Author |
pitrou |
| Recipients |
Arfrever, Jim.Jewett, asvetlov, gregory.p.smith, gvanrossum, ncoghlan, pitrou, r.david.murray, skrah, vstinner |
| Date |
2012年04月01日.16:39:05 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1333298039.3449.11.camel@localhost.localdomain> |
| In-reply-to |
<1333297625.14.0.513992446401.issue14417@psf.upfronthosting.co.za> |
| Content |
> 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.
I find this a bit lacking. Production code is used in all kinds of
settings that we didn't simulate here. Besides, a very sporadic bug is
no better than an easily reproduced one. The tracker already has its
share of people pointing at weird sporadic errors in their log files.
> 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*.
Depends on the application really. |
|