[issue30030] Simplify _RandomNameSequence

STINNER Victor added the comment: No consensus was found on this issue how to "simplify" _RandomNameSequence, so I close the issue. -- resolution: -> rejected status: open -> closed ___ Python tracker

[issue30030] Simplify _RandomNameSequence

STINNER Victor added the comment: "Generating every name consumes about 16 random bytes. This can exhaust the system entropy and slowdown other applications." Crys and Alex_Gaynor confirmed me on IRC that these two assumptions are both wrong. See for example

[issue30030] Simplify _RandomNameSequence

Serhiy Storchaka added the comment: On Linux creating a temporary file or directory usually consumes only one random name. But due to a bug on Windows (issue22107) it can consume up to TMP_MAX (2147483647 on Windows) names when called with read-only directory. Generating every name consumes

[issue30030] Simplify _RandomNameSequence

Serhiy Storchaka added the comment: test_threadedtempfile passed on Linux, but randomly failed on Windows. :( And _RandomNameSequence is used not only in tempfile. I suggest to wait until add a wrapper that makes generators thread-safe. Since it added we could restore the generator

[issue30030] Simplify _RandomNameSequence

STINNER Victor added the comment: > Remoe _get_candidate_names() and the global _name_sequence I understood the rationale behind _get_candidate_names() is to prevent generating the same name when _RandomNameSequence() uses random.Random. Since my change uses random.SystemRandom, I consider

[issue30030] Simplify _RandomNameSequence

Serhiy Storchaka added the comment: This isn't a different approach and this doesn't work because generators are not thread-safe. -- ___ Python tracker

[issue30030] Simplify _RandomNameSequence

STINNER Victor added the comment: I reopen the issue to propose a different approach: https://github.com/python/cpython/pull/1191 replaces Random with SystemRandom and drops get_candidate_names(). @Serhiy: I hesitated to add you as a co-author, but I'm not sure that you like my approach :-)

[issue30030] Simplify _RandomNameSequence

Changes by STINNER Victor : -- pull_requests: +1319 ___ Python tracker ___ ___

[issue30030] Simplify _RandomNameSequence

Serhiy Storchaka added the comment: Thank you Victor. I was going to do this but was unable to do this because I was out of my developing environment. -- resolution: -> rejected status: open -> closed ___ Python tracker

[issue30030] Simplify _RandomNameSequence

STINNER Victor added the comment: New changeset 1e62bf145b4865d03a29a5720a4eb84c321a9829 by Victor Stinner in branch 'master': bpo-30030: Revert f50354ad (tempfile) (#1187) https://github.com/python/cpython/commit/1e62bf145b4865d03a29a5720a4eb84c321a9829 --

[issue30030] Simplify _RandomNameSequence

STINNER Victor added the comment: Until a solution is found, I proposed to revert the change to "repair" buildbots. See also the python-ideas thread: [Python-ideas] Thread-safe generators https://mail.python.org/pipermail/python-ideas/2017-April/045427.html --

[issue30030] Simplify _RandomNameSequence

Changes by STINNER Victor : -- pull_requests: +1316 ___ Python tracker ___ ___

[issue30030] Simplify _RandomNameSequence

STINNER Victor added the comment: Why does _get_candidate_names() need a lock? Can't we produce enough entropy to reduce the risk of duplicate names in two threads? Maybe we should use SystemRandom instead, which would also avoid the need to testing if the pid changed. With one generator per

[issue30030] Simplify _RandomNameSequence

Serhiy Storchaka added the comment: Yes, it is related. :( If there is no easy way to make a generator working in multithread environment we need to revert this change. -- ___ Python tracker

[issue30030] Simplify _RandomNameSequence

STINNER Victor added the comment: The following builbot failure is probably related: http://buildbot.python.org/all/builders/AMD64%20Windows8.1%20Non-Debug%203.x/builds/623/steps/test/logs/stdio == FAIL: test_main

[issue30030] Simplify _RandomNameSequence

STINNER Victor added the comment: After reviewing the change, I created the issue #30051: "Document that the random module doesn't support fork". -- ___ Python tracker

[issue30030] Simplify _RandomNameSequence

Serhiy Storchaka added the comment: Merged in f50354adaaafebe95ad09d09b825804a686ea843. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue30030] Simplify _RandomNameSequence

Serhiy Storchaka added the comment: The downside of this change: 1. The _RandomNameSequence iterator no longer has the rng field. But it isn't used in the stdlib. And since _RandomNameSequence is a private name, it shouldn't be used in third-party code. 2. The result of no longer copyable

[issue30030] Simplify _RandomNameSequence

Changes by Serhiy Storchaka : -- pull_requests: +1219 ___ Python tracker ___ ___

[issue30030] Simplify _RandomNameSequence

New submission from Serhiy Storchaka: _RandomNameSequence was added in issue589982 when generator functions were new optional feature. _RandomNameSequence is implemented as an iterator class. Proposed patch simplifies _RandomNameSequence by implementing it as a generator function. This is a