This is the last major structural refactoring proposal to come out of the prep work on the PEP 432 modular bootstrapping feature development branch: 

* rename Python/random.c -> Python/hash_randomization.c
* rename _PyRandom_Init -> __Py_HashRandomization_Init
* rename _PyRandom_Fini -> __Py_HashRandomization_Fini

The current naming is confusing when working on the interpreter startup sequence as the file and API naming looks like it relates to initialising the random module, when it has nothing to do with that.

This is not just about the hash randomization. The file also contains implementations of _PyOS_URandom() and _PyOS_URandomNonblock().

You're right, I forgot about that part (I was mainly looking at the diffs today).

Spelling out the *problem*, rather than just jumping to a specific proposed solution, the confusing code layout we currently have is:

* Modules/_randommodule.c provides _random.Random
* Include/pylifecycle.c declares (amongst other things):
  * _PyRandom_Init
  * _PyRandom_Fini
  * _PyOS_URandom
  * _PyOS_URandomNonBlock
* Python/random.c implements all four of those APIs

I don't believe the latter two APIs existed back when I started the PEP 432 feature branch, which is why I had forgotten about them in this context.

Having the OS independent _PyOS_URandom APIs in a file called "Python/random.c" is reasonable, and there's even a legitimate connection to the random module there by way of random.SystemRandom.

So the only confusing aspect is also having the hash randomisation initialisation functions in there, rather than in their own file, with more appropriate API names.

Actually _PyRandom_Fini() has a relation to _PyOS_URandom APIs. It releases resources acquired by _PyOS_URandom APIs. It shouldn't be renamed to _Py_HashRandomization_Fini.

_PyRandom_Init() just initializes _Py_HashSecret. But it can't be implemented via _PyOS_URandom APIs. It uses a static function from this file. If move it to other place, we should add new _PyOS_URandom API function. I don't think this would make the code cleaner.

Nick: As Serhiy explained, IMHO you misunderstood _PyRandom_Init() and _PyRandom_Fini(), I suggest to close the issue.

FWIW, I concur with Nick's initial observation that the current "API naming looks like it relates to initialising the random module, when it has nothing to do with that."

It would be nice if Python/random.c were renamed to something else that indicated its relation to urandom and to hash secrets.

On 1 Jan 2017 05:00, "Raymond Hettinger" <report@bugs.python.org> wrote:

It would be nice if Python/random.c were renamed to something else that
indicated its relation to urandom and to hash secrets.

Right, based on Victor & Serhiy's feedback, the split I would now propose
 is:

- Include/pyurandom.h and Python/pyurandom.c for the OS urandom APIs (with
related init/fini functions)
- Python/hash_randomization.c for the hash seeding functions  (while this
process *uses* pyurandom, it isn't part of *providing* that interface)

As part of the startup sequence refactoring, this file has been renamed to Python/bootstrap_hash.c, and _PyRandom_Init/Fini have been renamed to _Py_HashRandomization_Init/Fini.

Relevant commit: https://github.com/python/cpython/commit/6b4be195cd8868b76eb6fbe166acc39beee8ce36#diff-5c57849694577deb1e10475ae796f7dc

I prefered random.c name since hash initialization is only a small part of
the file, most of file is the implementation of os.urandom() and
os.getrandom() which is used a runtime.

Aye, but the reason they're here rather than in the os module where you might otherwise expect to find them is because the hash randomization bootstrapping needs them.