So I still don't see why we need os.getrandom() --
it has nothing to recommend it over the secrets module (since
both won't happen before 3.6).
I have two reasons, neither of which I think are necessarily all
that persuasive. Don't consider this an argument--merely some
observations.
First, simply as a practical matter: the secrets module is currently
pure Python. ISTM that the os module is where we put miscellaneous
bits of os functionality; getrandom() definitely falls into that
category. Rather than adding a new _secrets module or whatever it
seemed easiest just to add it there.
Second, I'd put this under the "consenting adults" rule. Clearly
cryptography is a contentious subject with sharply differing
opinions. There are many, many cryptography libraries available on
PyPi; perhaps those libraries would like to use getrandom(), or
/dev/urandom, or even getentropy(), in a way different than how
secrets does it. My thinking is, the os module should provide
platform support, the secrets module should be our codified
best-practices, and we encourage everyone to use secrets. I'd go so
far as to add that recommendation to the doc *and* the docstrings of
os.urandom(), random.SystemRandom, and os.getrandom() (and
os.getentropy()) if we add it. But by providing the OS
functionality in a neutral way we allow external cryptographers to
write what *they* view as best-practices code without wading into
implementation detalis of secrets, or using ctypes, or whatnot.
But like I said I don't have a strong opinion. As long as we're not
adding mysterious flags to os.urandom() I'll probably sit the rest
of this one out.