I only looked at the Python part, and no, it's not good.
Documentation for the random module¹ prominently warns:
The pseudo-random generators of this module should not be used for security purposes. Use os.urandom() or SystemRandom if you require a cryptographically secure pseudo-random number generator.
I'm no cryptographer, but while the warning is valid, I don't think it's crucial here.
There are two potential sources of problem, the seed and the PRNG. The seed should be OK, because Python will use urandom as long as it's available in the system. As for the PRNG, a non-secure one shouldn't be used in encryption because it has statistically predictable behavior, but as far as I know that requires access to the ciphertext, which isn't the case here.
Still, replacing random with SystemRandom is easy and would fix the problem.
Okay, I don't study this, but I don't think that's what "cryptographically secure pseudo-random number generator" means. Not all things vaguely related to cryptography are required a CSPRNG and these answers are not being used cryptographically at all in many cases (like you just reading it over the phone to the representative). Please correct me if I'm wrong.
A bog-standard RNG might generate passwords depending on what second you ran it, so an attacker can easily make a list of all the passwords generated in a specific month or year.
People have lost a lot of bitcoins this way.
It might be okay for a security question, but better safe than sorry. Just use a secure generator for everything.
Documentation for the random module¹ prominently warns:
The pseudo-random generators of this module should not be used for security purposes. Use os.urandom() or SystemRandom if you require a cryptographically secure pseudo-random number generator.
¹ https://docs.python.org/2/library/random.html