If an object containing a random.Random instance is pickled on a 64-bit platform, unpickling the result on a 32-bit platform can cause an OverflowError:

  File "/usr/local/lib/python2.4/random.py", line 140, in __setstate__
    self.setstate(state)
  File "/usr/local/lib/python2.4/random.py", line 125, in setstate
    super(Random, self).setstate(internalstate)
OverflowError: long int too large to convert to int

I wasn't able to find any other tickets referring specifically to this.  This is in Python 2.4.1 for sure, may be in later versions.

I've had this same problem with 2.5.1

Pickling random.getstate() on 64bit and then loading it back with
random.setstate() on 32bit does not work (crashes because of trying cast
64bit ints to 32bit).

The other way around is even worse. It loads but is in a faulty state,
where for example:
>>> random.randrange(1000)
49801980494

This seems like a bug to me.

Would anybody of you like to work on a patch?

I've got a patch! The problem was that the state was being cast from a
C-type unsigned long to a long.

On 32-bit machines this makes large 32-bit longs negative.
On 64-bit machines this preserves the sign of 32-bit values (because
they are stored in 64-bit longs).

My patch returns the values with PyLong_FromUnsignedLong() instead of
PyInt_FromLong(), therefore there is no casting to long and both 32-bit
and 64-bit machines produce the same result.

I added code to read states from the old (buggy) version and decypher it
appropriately (from either 32-bit or 64-bit source!). In other words,
old pickles can now be opened on either architecture with the new patch.

This patch is taken from the svn head, but also works on Python 2.5.1 .

I haven't tested this patch fully on 64-bit machine yet. I'll let you
know when I have.

Cheers,
-Shawn

Yep, tested it on a 64-bit machine and 2 32-bit machines and back and
forth between them. It seems to resolve the problem.

For the record, and to prevent dilution of the count of times this bug has 
been encountered: this issue is a duplicate of issue1472695, which was 
later marked "won't fix" for no apparent reason. sligocki's patch is more 
thorough than mine was and I hope it has a better fate too.

Thanks for the patch. Committed as r59295.

Because of the version change, the patch cannot be applied to 2.5.x