> One benefit of having a type code for 'long double' (assuming you are
> mapping the value to the platform's 'long double') is that the you
> don't have to know how many bytes are in the underlying representation.

Agreed:  it's nice to have struct.pack already know your machine.

Actually, this brings up (yet) another open question:  native packing/unpacking of a long double would presumably return something corresponding to the platform long double, as above;  but non-native packing/unpacking should do something standard, instead, for the sake of interoperability between platforms.  Currently, I believe that packing a Python float always---even in native mode---packs in IEEE 754 format, even when the platform doubles aren't IEEE 754.

For native packing/unpacking, I'm slowly becoming convinced that unpacking as a ctypes long double is the only thing that makes any sense, so that we keep round-tripping, as you point out.  The user can easily enough extract the Python float for numerical work.  I still don't like having the struct module depend on ctypes, though.