gotcha or bug? random state reset on irrelevant import

[Alan Isaac]

Running test.py will print False.
Is this expected/desirable?
Thanks,
Alan Isaac


%%%%%%% test.py %%%%%%%%%%%
from random import seed, getstate
seed(217)
x = getstate()
from test2 import Trivial
y = getstate()
print x == y


%%%%% test2.py %%%%%%%%%%%%%
from random import seed
seed(314)
class Trivial:
pass

 

[James Stroud]

Running test.py will print False.
Is this expected/desirable?
Thanks,
Alan Isaac


%%%%%%% test.py %%%%%%%%%%%
from random import seed, getstate
seed(217)
x = getstate()
from test2 import Trivial
y = getstate()
print x == y


%%%%% test2.py %%%%%%%%%%%%%
from random import seed
seed(314)
class Trivial:
pass

Yes. To circomvent this, use

from random import seed

class Trivial:
pass

if __name__ == "__main__":
seed(314)

 

[John Machin]

Running test.py will print False.
Is this expected/desirable?
Thanks,
Alan Isaac


%%%%%%% test.py %%%%%%%%%%%
from random import seed, getstate
seed(217)
x = getstate()
from test2 import Trivial

It's not irrelevant; the test2 module has to be *executed* as part of
the import. Yes, "class" is an executable statement. Just about every
Python statement is executable. seed(314) is executed.

y = getstate()
print x == y


%%%%% test2.py %%%%%%%%%%%%%
from random import seed

Insert here:
print "before seed call"

seed(314)

Insert here:
print "have just executed some relevant code"

class Trivial:
pass

HTH,
John

 

[Alan Isaac]

It's not irrelevant; the test2 module has to be *executed* as part of
the import. [...] seed(314) is executed.

OK, I understand this is the right answer.
But another way to look at the question is:
is it a good design to only be able to use seed
to set a global state? (See for contrast
numpy.random, for which my appreciation
has just increased yet again.)

Cheers,
Alan Isaac

 

[Alan Isaac]

if __name__ == "__main__":
seed(314)

Thanks for this suggestion.
Alan Isaac

 

[Alex Martelli]

It's not irrelevant; the test2 module has to be *executed* as part of
the import. [...] seed(314) is executed.

OK, I understand this is the right answer.
But another way to look at the question is:
is it a good design to only be able to use seed
to set a global state? (See for contrast
numpy.random, for which my appreciation
has just increased yet again.)

What do you mean? Just instantiate the random.Random class and you can
call .seed on it as well as anything else, and no other module will
infringe on "your" module's Random instance. The "global functions" of
module random exist for those who *SPECIFICALLY* want globally shared
behavior, of course.


Alex

 

[Alan Isaac]

Alex Martelli said:

What do you mean? Just instantiate the random.Random class and you can
call .seed on it as well as anything else, and no other module will
infringe on "your" module's Random instance. The "global functions" of
module random exist for those who *SPECIFICALLY* want globally shared
behavior, of course.

I consider this an unduly kind response.
"RTFM" would have been appropriate.

The functions supplied by this module are actually bound
methods of a hidden instance of the random.Random class.
You can instantiate your own instances of Random to get generators that
don't share state.

Sheesh. I must have been asleep when reading the documentation.

Thanks,
Alan