> The pickle output has the sign-bit set. Ignoring the sign-bit, it is 
> unpickled correctly.

Okay, thanks for the clarification.  I just wanted to be clear whether there's a real problem with pickle that should be fixed in 2.7 or not.

Again, I don't see this as a bug:  pickle is transferring the sign bit correctly, so the only issue again is that float('nan') happens to produce a nan whose sign bit is set (depending on platform, compiler options, etc.).  I don't see it as a problem that one can end up with some 'positive' nans and some 'negative' nans on a single system.  As far as I know, none of this violates any documentation or standards (IEEE 754 explicitly places no interpretation on the sign bit of a nan, and makes no guarantees or recommendations about the sign bit of the result of converting the string 'nan').  So at worst, this is a minor violation of user expectations.  Though I do agree that having float('-nan') having its sign bit unset is especially surprising.

So while I don't see this as a bug that should be fixed for 2.7, I'm happy to 'fix' this for Python 3.3, partly for the portability improvement, and partly to avoid having the string-to-float conversions do INF*0 calculations at run time;  that bit's always made me feel uncomfortable.

Thanks for the updated patch;  I'll take a look shortly.