[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
Terry Reedy
tjreedy at udel.edu
Sat Jun 11 13:28:33 EDT 2016
More information about the Python-Dev mailing list
Sat Jun 11 13:28:33 EDT 2016
- Previous message (by thread): [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
- Next message (by thread): [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 6/11/2016 11:34 AM, Guido van Rossum wrote: > In terms of API design, I'd prefer a flag to os.urandom() indicating a > preference for > - blocking > - raising an exception > - weaker random bits +100 ;-) I proposed exactly this 2 days ago, 5 hours after Larry's initial post. ''' I think the 'new API' should be a parameter, not a new function. With just two choices, 'wait' = True/False could work. If 'raise an exception' were added, then 'action (when good bits are not immediately available' = 'return (best possible)' or 'wait (until have good bits)' or 'raise (CryptBitsNotAvailable)' In either case, there would then be the question of whether the default should match 3.5.0/1 or 3.4 and before. ''' Deciding on this then might have saved some hurt feelings, to the point where two contributors feel like disappearing, and a release manager must feel the same. In any case, Guido already picked 3.4 behavior as the default. Can we agree and move on? -- Terry Jan Reedy
- Previous message (by thread): [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
- Next message (by thread): [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list