This is a lot heavier on the code/hacking than usual for my blog. I'd be interested in hearing whether y'all like it more or less than usual.

Adding some technical details to your posts enlarges your audience.

I like this post as well as previous ones.

Another solution is to save state of the (pseudo)random generator and then restore it. In python: random.getstate()and random.setstate().

The only problem with that is that a termination of your code in between those two points (which could be caused by an exception, a client timeout, etc) leaves you right back where we started.

You can use begin/rescue/ensure (Ruby's try/catch/finally) to try to prevent that, but it strikes me as unclean. In addition to having to catch a very wide scope of exceptions, I'm not sure you can actually ensure the ensure block executes. (A trivial example: suppose I call out to library code that I don't understand and, for whatever reason, it calls exit. The ensure block will not execute. Granted, that would take care of my problem because the process was dead, but speaking generally, it is dangerous to assume that ensure actually ensures anything in generic circumstances.)

Right. It seems we are closer to conclusion that side effects are bad.

Functional programming on the horizon?

Python lets you instantiate Random objects with a pre-set seed, so you don't have to risk doing anything that might affect the global state. Try this at an interactive prompt:

    import random
    r = random.Random("myseed")
    r.random()
    r.random()
    r.random()
    r2 = random.Random("myseed")
    r2.random()
    r2.random()
    r2.random()

Both sequences of random numbers will be the same.

You are perfectly right.

I was talking about source of patio11's problem which arose from modifying global state.