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.