About long doubles again:  I just encountered someone on the #python IRC channel who wanted to know whether struct.pack and struct.unpack supported reading and writing of x87 80-bit long doubles (padded to 12 bytes each in the input).  A few quotes from him/her, with permission (responses from others, including me, edited out;  I can supply a fuller transcript if necessary, but I hope what's below isn't misleading).

[18:39] bdesk: Hi, is struct.pack able to handle 80-bit x86 extended floats?
[18:40] bdesk: How can I read and write these 80-bit floats, in binary, using python?
[18:44] bdesk: dickinsm: I have a C program that uses binary files as input and output, and I want to deal with these files using python if possible.
[18:49] bdesk: I don't need to do arithmetic with the full 80 bits of precision within the python program, although It would be better if I could.
[18:50] bdesk: I would need to use the float in a more semantically useful manner than treating it as a black box of 12 bytes.
[18:55] bdesk: Until python gets higher precision floats, my preferred interface would be to lose some precision when unpacking the floats.

The main thing that I realized from this is that unpacking as a ctypes long double isn't all that useful for someone who wants to be able to do arithmetic on the unpacked result.  And if you don't want to do arithmetic on the unpacked result, then you're probably just shuffling the bytes around without caring about their meaning, so there's no need to unpack as anything other than a sequence of 12 bytes.

On the other hand, I suppose it's enough to be able to unpack as a ctypes c_longdouble and then convert to a Python float (losing precision) for the arithmetic.  Alternatively, we might consider simply unpacking a long double directly into a Python float (and accepting the loss of precision);  that seems to be what would be most useful for the use-case above.