| msg314969 - (view) |
Author: Wolfgang Maier (wolma) * |
Date: 2018-04-05 08:50 |
| A rather trivial change: tempfile._RandomNameSequence could make use of random.Random.choices introduced in 3.6. IMO, the suggested change would give clearer and also faster code. It also updates the docstring of the class, which currently talks about a six-character string, when an eight-character string gets returned. |
|
|
| msg314974 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) *  |
Date: 2018-04-05 10:01 |
| See . It affects Random.choices(), but not Random.choice() because the latter uses getrandbits(). |
|
|
| msg314975 - (view) |
Author: Inada Naoki (methane) * |
Date: 2018-04-05 10:18 |
| @wolma Would you split your PR? One for fix docstring and one for using Random.choices. Since former is document bug, I want to backport it. (while _RandomNameSequence is private) |
|
|
| msg314979 - (view) |
Author: Wolfgang Maier (wolma) * |
Date: 2018-04-05 11:47 |
| @serhiy as I understand issue 33228, the double rounding problem potentially causing an IndexError can only affect choices() if the len of the sequence to choose from is greater than 2049, but the string in question here is only 37 characters long. Alternatively, choices may fail with certain weights (https://bugs.python.org/msg275594), but _RandomNameSequence is not using weights. |
|
|
| msg314980 - (view) |
Author: Wolfgang Maier (wolma) * |
Date: 2018-04-05 11:48 |
| sorry, should have been issue 24567, of course. |
|
|
| msg314981 - (view) |
Author: Wolfgang Maier (wolma) * |
Date: 2018-04-05 11:56 |
| Actually, in Python2.7 random.choice is implemented with the same susceptibility to the rounding bug as Python3's choices, still nobody ever reported a tempfile IndexError problem (I guess). |
|
|
| msg314994 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2018-04-05 16:41 |
| -0 on making anything other than the doc change. For the most part, we avoid sweeping through the standard library to substitute-in new features and instead have a preference for code stability rather than code churn. FWIW, the main rationale for introducing choices() was to support weighting. Existing code that calls choice() multiple times is still correct and clear. |
|
|
| msg339598 - (view) |
Author: Inada Naoki (methane) * |
Date: 2019-04-08 08:20 |
| I'm +0 too. Since there are no +1 from core dev for a long time, I close this issue for now. |
|
|