Bugs item #1472695, was opened at 2006-04-18 20:10
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472695&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Peter Maxwell (pm67nz)
Assigned to: Raymond Hettinger (rhettinger)
Summary: 32/64bit pickled Random incompatiblity
Initial Comment:
The unsigned long integers which make up the state of a Random
instance are converted to Python integers via a cast to long in
_randommodule.c's random_getstate function, so on a 32bit platform
Random.getstate() returns a mix of postitive and negative integers, while
on a 64bit platform the negative numbers are replaced by larger positive
numbers, their 32bit-2s-complement equivalents.
As a result, unpicking a Random instance from a 64bit machine on a 32bit
platform produces the error "OverflowError: long int too large to convert
to int". Unpickling a 32bit Random on a 64bit machine succeeds, but the
resulting object is in a slightly confused state:
>>> r32 = cPickle.load(open('r32_3.pickle'))
>>> for i in range(3):
... print r64.random(), r32.random()
...
0.237964627092 4292886520.32
0.544229225296 0.544229225296
0.369955166548 4292886520.19
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2006-04-25 19:26
Message:
Logged In: YES
user_id=31435
> do you think we should require that the world not
> change for 32-bit pickles?
I don't understand the question. If a pre-2.5 pickle here
can be read in 2.5, where both producer & consumer are the
same 32-vs-64 bit choice; and a 2.5+ pickle here is portable
between 32- and 64- boxes, I'd say "good enough".
While desirable, it's not really critical that a 2.5 pickle
here be readable by an older Python. While that's critical
for pickle in general, and critical too for
everyone-uses-'em types (ints, strings, lists, ...), when
fixing a bug in a specific rarely-used type's pickling
strategy some slop is OK. IOW, it's just not worth heroic
efforts to hide all pain. The docs should mention
incompatibilities, though.
Does that answer the question?
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2006-04-25 18:00
Message:
Logged In: YES
user_id=80475
Tim, do you think we should require that the world not
change for 32-bit pickles?
----------------------------------------------------------------------
Comment By: Peter Maxwell (pm67nz)
Date: 2006-04-21 01:03
Message:
Logged In: YES
user_id=320286
OK, here is a candidate patch, though I don't know if it is the best way
to do it
or meets the style guidelines etc. It makes Random pickles interchangable
between 32bit and 64bit machines by encoding their states as Python long
integers. An old pre-patch 32bit pickle loaded on a 64bit machine still
fails
(OverflowError: can't convert negative value to unsigned long) but I hope
that
combination is rare enough to ignore. Also on a 32bit machine new Random
pickles can't be unpickled by a pre-patch python, but again there are
limits to
sane backward compatability.
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-19 02:02
Message:
Logged In: YES
user_id=33168
Peter, thanks for the report. Do you think you could work
up a patch to correct this problem?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472695&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
