This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mark.dickinson
Recipients MrJean1, ajaksu2, barry, benjamin.peterson, mark.dickinson, meador.inge, pitrou, teoliphant
Date 2010-02-22.16:14:46
SpamBayes Score 8.1779135e-08
Marked as misclassified No
Message-id <1266855288.06.0.620082490934.issue3132@psf.upfronthosting.co.za>
In-reply-to
Content
> 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.
History
Date User Action Args
2010-02-22 16:14:48mark.dickinsonsetrecipients: + mark.dickinson, barry, teoliphant, pitrou, ajaksu2, MrJean1, benjamin.peterson, meador.inge
2010-02-22 16:14:48mark.dickinsonsetmessageid: <1266855288.06.0.620082490934.issue3132@psf.upfronthosting.co.za>
2010-02-22 16:14:46mark.dickinsonlinkissue3132 messages
2010-02-22 16:14:46mark.dickinsoncreate