Message183916
| Author |
rhettinger |
| Recipients |
Arfrever, brett.cannon, mark.dickinson, rhettinger, scoder, serhiy.storchaka |
| Date |
2013年03月11日.02:53:34 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1362970415.74.0.838766572394.issue16659@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
[Serhiy Storchaka]
> I don't want to make a decision on the inclusion of this code.
It was a tough call, but I don't want to add this code. You've a great job with it, but I don't think it is a worthwhile endeavor.
* The algorithm was designed with C level operations in mind and is awkward in Python.
* The code we use for MT has been widely distributed and tested by others. We would just be getting away from the canonical reference version.
* The other implementations already have an MT, so this code won't end-up being used and would just add to the maintenance burden. If anyone ever did use it, it would be dog slow.
-----------
P.S. I did have a question about the patch.
The code uses an RLock. Where are the places that can trigger reentracy?
With in a single method, successive calls to _genrand_int32() are ordered and can't be interleaved with reentrancy while still keeping the original order of generated random numbers. |
|