Mark Dickinson <dicki...@gmail.com> added the comment: > 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue3132> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
