@delph: Sounds good(ot!). I've no experience of your learning material, but maybe I'll even see if it can inspire me.
@nen: What was the issue? Trying to get a sensible output?
(At the most basic, maybe just emulate dice. Run a "D6" 100 times, if you need to check you've properly implemented 1..6 as ~16 chances of getting each[1]. Then you can expand/generalise it to handle "2D6", "3D20", "D3-2" (i.e. -1..+1), etc.)
Or deciding what the sensible outputs ought to be?
(That's game-balancing issues. But if you have an idea what stats a basic Level 1 character has, you could run permutations of what results they get against your ideas of the test they may encounter (vs, say, a L1 Enemy) and see what percentage of encounters, or rounds of action, go the player's way. You can write this as an 'off-game interface', either copying the shared bits back and forth between that and the 'real' thing for testing/integrating, or make that an includable module/resourcs/whatever-it's-called-in-Python.)
Maybe something else? I know I've thought things like "I won't include a map/diagram of the procedurally-generated environment's connections for a player, but I'd quite like to see one for development", at times, only to send me down my own personal rabbithole of basically reinventing my own Visio but in PerlTk, forgetting that this was never what I actually needed. Did you go beyond the necessary (such as either of the above examples, if you felt either were actually that, bare-bone output that's maybe even just straight to console and quit)... Or some other diversion/distraction? I can probably relate, whichever way!
[1] Rather than getting the 0<=fraction<1 multiplied wrongly for your own expansion of the basic rand(), or the range 0..n-1 from explicit rand(n); to which you might need to +1. Assuming Python does it that way, which I'd maybe assume it did but then test as described to confirm.