Skip to content

bpo-33228: Use Random.choices in tempfile #6383

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

wm75
Copy link

@wm75 wm75 commented Apr 5, 2018

Using Random.choices instead of Random.choice in
the tempfile._RandomNameSequence class makes the code more
readable and faster.
This commit also updates the docstring of the class.

https://bugs.python.org/issue33228

Using Random.choices instead of Random.choice in
the tempfile._RandomNameSequence class makes the code more
readable and faster.
This commit also updates the docstring of the class.
c = self.characters
choose = self.rng.choice
letters = [choose(c) for dummy in range(8)]
letters = self.rng.choices(self.characters, k=8)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think these kinds of trivial changes should be done. There should be a preference for code stability.

@1st1
Copy link
Member

1st1 commented Apr 5, 2018

How much "faster" does it make the code? Do you have a use case for which you need to optimize tempfile?

@wm75
Copy link
Author

wm75 commented Apr 5, 2018

Well, _RandomNameSequence would get a bit more than 2x faster, but, of course, in the context of tempfile almost all public functions will be IO limited anyway, and the performance gain in this one class will be completely irrelevant.
No, I don't have a use case that needs this optimization. Rather I was coming across this, while working on #6291, when I was checking where in the stdlib random.Random gets used.
If you think this is not worth the effort, feel free to just close it, I won't mind 😃

@wm75
Copy link
Author

wm75 commented Apr 7, 2018

@methane, I split out the docstring change into a separate PR #6414 like you asked for.

@rhettinger @1st1 if the remainder of this PR is not worth it, it can be closed without any loss now.

@methane methane closed this Apr 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants