To provide some additional context to that answer: the problem isn't with folks wanting direct access to their hardware entropy devices as such.

There are plenty of options for that (such as exposing it as a file descriptor distinct from both /dev/random and /dev/urandom), but going through /dev/random (or calling "os.getrandom(n, os.GRND_RANDOM)") isn't one of them.

Instead, /dev/random consumes the same kernel CSPRNG that /dev/urandom does, it just adds an extra check to make it block when the kernel's collected entropy estimate happens to be low.

So this isn't something we want to expose or explain to Python users in general - instead, it's something that only folks doing highly specialised work involving hardware security modules might be interested in, and hence can be safely left to third party tools and frameworks, rather than being something that would ever be shipped by default as part of the reference interpreter and standard library.