pickle broken: can't handle NaN or Infinity under win32

[Grant Edwards]

I finally figured out why one of my apps sometimes fails under
Win32 when it always works fine under Linux: Under Win32, the
pickle module only works with a subset of floating point
values. In particular the if you try to dump/load an infinity
or nan value, the load operation chokes:
Under Linux:

$ python
Python 2.3.4 (#2, Feb 9 2005, 14:22:48)
[GCC 3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk)] on linux2
Type "help", "copyright" , "credits" or "license" for more information.

$ python pickletest.py
(inf, nan) (inf, nan)
Under Win32:

$ python
ActivePython 2.3.4 Build 233 (ActiveState Corp.) based on
Python 2.3.4 (#53, Oct 18 2004, 20:35:07) [MSC v.1200 32 bit (Intel)] on win32
Type "help", "copyright" , "credits" or "license" for more information.

$ python pickletest.py
Traceback (most recent call last):
File "pickletest.py" , line 8, in ?
d = pickle.loads(s)
File "C:\PYTHON23\li b\pickle.py", line 1394, in loads
return Unpickler(file) .load()
File "C:\PYTHON23\li b\pickle.py", line 872, in load
dispatch[key](self)
File "C:\PYTHON23\li b\pickle.py", line 968, in load_float
self.append(flo at(self.readlin e()[:-1]))
ValueError: invalid literal for float(): 1.#INF

I realize that this is probably due to underlying brokenness in
the Win32 libc implimentation, but should the pickle module
hide such platform-dependancies from the user?

Best case, it would be nice if pickle could handle all floats
in a portable way.

Worst case, shouldn't the pickle module documentation mention
that pickling floats non-portable or only partially implimented?

On a more immediate note, are there hooks in pickle to allow
the user to handle types that pickle can't deal with? Or, do I
have to throw out pickle and write something from scratch?

[NaN and Infinity are prefectly valid (and extremely useful)
floating point values, and not using them would require huge
complexity increases in my apps (not using them would probably
at least triple the amount of code required in some cases).]

--
Grant Edwards grante Yow! Yow!
at
visi.com

[Grant Edwards]

On 2005-06-21, Grant Edwards <gr****@visi.co m> wrote:

I finally figured out why one of my apps sometimes fails under
Win32 when it always works fine under Linux [...]

Oh, I forgot, here's pickletest.py:

#!/usr/bin/python
import pickle

f1 = (1e300*1e300)
f2 = f1/f1
o = (f1,f2)
s = pickle.dumps(o)
d = pickle.loads(s)

print o,d
$ python pickletest.py
(inf, nan) (inf, nan)
Under Win32:

$ python pickletest.py
Traceback (most recent call last):
File "pickletest.py" , line 8, in ?
d = pickle.loads(s)
File "C:\PYTHON23\li b\pickle.py", line 1394, in loads
return Unpickler(file) .load()
File "C:\PYTHON23\li b\pickle.py", line 872, in load
dispatch[key](self)
File "C:\PYTHON23\li b\pickle.py", line 968, in load_float
self.append(flo at(self.readlin e()[:-1]))
ValueError: invalid literal for float(): 1.#INF

--
Grant Edwards grante Yow! Here I am in 53
at B.C. and all I want is a
visi.com dill pickle!!

[Scott David Daniels]

Grant Edwards wrote:

I finally figured out why one of my apps sometimes fails under
Win32 when it always works fine under Linux: Under Win32, the
pickle module only works with a subset of floating point
values. In particular the if you try to dump/load an infinity
or nan value, the load operation chokes: There is no completely portable way to do this. Any single platform
can have a solution, but (since the C standards don't address how
NaNs and Infs are represented) there is not a good portable way to do
the pickle / unpickle. It is nice the exception is raised, since at
one point it was not (and a simple 1.0 was returned).
See explanations in article 654866:

http://sourceforge.net/tracker/index...70&atid=105470
$ python pickletest.py
Traceback (most recent call last): ...
File "C:\PYTHON23\li b\pickle.py", line 968, in load_float
self.append(flo at(self.readlin e()[:-1]))
ValueError: invalid literal for float(): 1.#INF I realize that this is probably due to underlying brokenness in
the Win32 libc implimentation, but should the pickle module
hide such platform-dependancies from the user? As mentioned above, there is no C standard-accessible way to
predictably build or represent NaNs, negative zeroes, or Infinities.
[NaN and Infinity are prefectly valid (and extremely useful)
floating point values, and not using them would require huge
complexity increases in my apps (not using them would probably
at least triple the amount of code required in some cases).]

You could check to see if the Python 2.5 pickling does a better
job. Otherwise, you've got your work cut out for you.

-Scott David Daniels
Sc***********@A cm.Org

[Grant Edwards]

On 2005-06-22, Scott David Daniels <Sc***********@ Acm.Org> wrote:

I finally figured out why one of my apps sometimes fails under
Win32 when it always works fine under Linux: Under Win32, the
pickle module only works with a subset of floating point
values. In particular the if you try to dump/load an infinity
or nan value, the load operation chokes:
There is no completely portable way to do this.

Python deals with all sorts of problems for which there is no
completely portable solution. Remember: "practicali ty beats purity."
Any single platform can have a solution, but (since the C
standards don't address how NaNs and Infs are represented)
there is not a good portable way to do the pickle / unpickle.
Likewise, there is no completely portable python
implimentation. Any single platform can have a Python
implimentation, but since the C standards don't address a
universal standard for "a computer" there is not a good
portable way to do Python. I guess we'd better give up on
Python. :)
It is nice the exception is raised, since at one point it was
not (and a simple 1.0 was returned).

That would be even worse.

[NaN and Infinity are prefectly valid (and extremely useful)
floating point values, and not using them would require huge
complexity increases in my apps (not using them would probably
at least triple the amount of code required in some cases).]

You could check to see if the Python 2.5 pickling does a better
job. Otherwise, you've got your work cut out for you.

Fixing it is really quite trivial. It takes less than a dozen
lines of code. Just catch the exception and handle it.

def load_float(self ):
s = self.readline()[:-1]
try:
f = float(s)
except ValueError:
s = s.upper()
if s in ["1.#INF", "INF"]:
f = 1e300*1e300
elif s in ["-1.#INF", "-INF"]:
f = -1e300*1e300
elif s in ["NAN","1.#QNAN" ,"QNAN","1.#IND ","IND","-1.#IND"]:
f = -((1e300*1e300)/(1e300*1e300))
else:
raise ValueError, "Don't know what to do with "+`s`
self.append(f)

Obviously the list of accepted string values should be expanded
to include other platforms as needed. The above example
handles Win32 and glibc (e.g. Linux).

Even better, add that code to float().

--
Grant Edwards grante Yow! Is the EIGHTIES
at when they had ART DECO
visi.com and GERALD McBOING-BOING
lunch boxes??

[Scott David Daniels]

Grant Edwards wrote:

On 2005-06-22, Scott David Daniels <Sc***********@ Acm.Org> wrote:

...Under Win32, the pickle module only works with a subset of
floating point values. In particular ... infinity or nan ...

There is no completely portable way to do this.

Python deals with all sorts of problems for which there is no
completely portable solution. Remember: "practicali ty beats purity."

Any single platform can have a solution, but (since the C
standards don't address how NaNs and Infs are represented)
there is not a good portable way to do the pickle / unpickle.

...
Fixing it is really quite trivial. It takes less than a dozen
lines of code. Just catch the exception and handle it.

Since you know it is quite trivial, and I don't, why not submit a
patch resolving this issue. Be sure to include tests for all
supported Python platforms.

--Scott David Daniels
Sc***********@A cm.Org

[Grant Edwards]

On 2005-06-22, Scott David Daniels <Sc***********@ Acm.Org> wrote:

Fixing it is really quite trivial. It takes less than a dozen
lines of code. Just catch the exception and handle it.

Since you know it is quite trivial, and I don't, why not
submit a patch resolving this issue. Be sure to include tests
for all supported Python platforms.

I'm working on it. I should have said it's trivial if you have
access to the platforms to be supported. I've tested a fix
that supports pickle streams generated under Win32 and glibc.
That's using the "native" string representation of a NaN or
Inf.

A perhaps simpler approach would be to define a string
representation for Python to use for NaN and Inf. Just because
something isn't defined by the C standard doesn't mean it can't
be defined by Python.

--
Grant Edwards grante Yow! I'm shaving!! I'M
at SHAVING!!
visi.com

[Scott David Daniels]

Grant Edwards wrote:

I'm working on it. I should have said it's trivial if you have
access to the platforms to be supported. I've tested a fix
that supports pickle streams generated under Win32 and glibc.
That's using the "native" string representation of a NaN or
Inf.

Several issues:
(1) The number of distinct NaNs varies among platforms. There are
quiet and signaling NaNs, negative 0, the NaN that Windows VC++
calls "Indeterminate, " and so on.
(2) There is no standard-conforming way to create these values.
(3) There is no standard-conforming way to detect these values.

--Scott David Daniels
Sc***********@A cm.Org

[Terry Reedy]

"Grant Edwards" <gr****@visi.co m> wrote in message
news:11******** *****@corp.supe rnews.com...

I'm working on it. I should have said it's trivial if you have
access to the platforms to be supported. I've tested a fix
that supports pickle streams generated under Win32 and glibc.
That's using the "native" string representation of a NaN or
Inf.

A perhaps simpler approach would be to define a string
representation for Python to use for NaN and Inf. Just because
something isn't defined by the C standard doesn't mean it can't
be defined by Python.

I believe that changes have been made to marshal/unmarshal in 2.5 CVS with
respect to NAN/INF to eliminate annoying/surprising behavior differences
between corresponding .py and .pyc files. Perhaps these revisions would be
relevant to pickle changes.

TJR

[Grant Edwards]

On 2005-06-22, Scott David Daniels <Sc***********@ Acm.Org> wrote:

I'm working on it. I should have said it's trivial if you have
access to the platforms to be supported. I've tested a fix
that supports pickle streams generated under Win32 and glibc.
That's using the "native" string representation of a NaN or
Inf. Several issues:

(1) The number of distinct NaNs varies among platforms.
According to the IEEE standard, there are exactly two:
signalling and quiet, and on platforms that don't impliment
floating point exceptions (probably in excess of 99.9% of
python installations), the difference between the two is moot.
There are quiet and signaling NaNs, negative 0,
Negative 0 isn't a NaN, it's just negative 0.
the NaN that Windows VC++ calls "Indeterminate, " and so
on.
That's just Microsoft's way of spelling "signalling NaN."
(2) There is no standard-conforming way to create these values.
What standard are you looking at? My copy of the IEEE 754
standard is pretty clear.
(3) There is no standard-conforming way to detect these
values.

The bit patterns are defined by the IEEE 754 standard. If
there are Python-hosting platoforms that don't use IEEE 754 as
the floating point representation, then that can be dealt with.

Python has _tons_ of platform-specific code in it.

Why all of a sudden is it taboo for Python to impliment
something that's not universally portable and defined in a
standard? Where's the standard defining Python?

--
Grant Edwards grante Yow! ... A housewife
at is wearing a polypyrene
visi.com jumpsuit!!

[Terry Reedy]

"Grant Edwards" <gr****@visi.co m> wrote in message
news:11******** *****@corp.supe rnews.com...

The bit patterns are defined by the IEEE 754 standard. If
there are Python-hosting platoforms that don't use IEEE 754 as
the floating point representation, then that can be dealt with.

Python has _tons_ of platform-specific code in it.
More, I believe, than the current maintainers would like. Adding more
would probably require a commitment to maintain the addition (respond to
bug reports) for a few years.
Why all of a sudden is it taboo for Python to impliment
something that's not universally portable and defined in a
standard?
??

Perhaps you wrote this before reading my last post reporting that some
NaN/Inf changes have already been made for 2.5. I believe that more would
be considered if properly submitted.
Where's the standard defining Python?

The Language and Library Reference Manuals at python.org.

Terry J. Reedy