[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits? (original) (raw)
Terry Reedy tjreedy at udel.edu
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 ]