There's some NaN behaviour that needs fixing in the packing code: packing a NaN currently creates a signalling NaN rather than a quiet NaN, and the sign of a NaN isn't respected. (One can make a strong argument that the sign of the NaN doesn't matter, but we're respecting the sign for '<d' and '<f' formats, so I think we should do the same for '<e'.)

I'm working on an updated patch, taking into account the above and Antoine and Raymond's comments.

This is the behaviour with the current patch, on OS X 10.10.5.

>>> '{:064b}'.format(struct.unpack('<Q', struct.pack('<d', math.nan))[0])
'0111111111111000000000000000000000000000000000000000000000000000'
>>> '{:032b}'.format(struct.unpack('<I', struct.pack('<f', math.nan))[0])
'01111111110000000000000000000000'
>>> '{:016b}'.format(struct.unpack('<H', struct.pack('<e', math.nan))[0])
'0111110000000001'
>>> '{:064b}'.format(struct.unpack('<Q', struct.pack('<d', -math.nan))[0])
'1111111111111000000000000000000000000000000000000000000000000000'
>>> '{:032b}'.format(struct.unpack('<I', struct.pack('<f', -math.nan))[0])
'11111111110000000000000000000000'
>>> '{:016b}'.format(struct.unpack('<H', struct.pack('<e', -math.nan))[0])
'0111110000000001'