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 fil
Recipients alex, fil, francismb, mark.dickinson, meador.inge, pitrou, skrah, tim.peters
Date 2013-12-09.00:34:26
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1386549266.38.0.317241267185.issue19904@psf.upfronthosting.co.za>
In-reply-to
Content
Stefan, performance is not the principle motivator here: the intention is that it is just sensible to support this integer type, just like supporting int64 since it is an intrinsic type supported by CPU's.

Of course any integer length could be handled by memoryview unpacker, but this would not really make sense for int64. My view is that any intrinsic type (ie. register type) is the key point at which it should be supported by struct, and not a custom unpacker. 128/256/512 bit integers are in this category..

Principally this is so that it can be used by ctypes (see #19905).
History
Date User Action Args
2013-12-09 00:34:26filsetrecipients: + fil, tim.peters, mark.dickinson, pitrou, alex, skrah, meador.inge, francismb
2013-12-09 00:34:26filsetmessageid: <1386549266.38.0.317241267185.issue19904@psf.upfronthosting.co.za>
2013-12-09 00:34:26fillinkissue19904 messages
2013-12-09 00:34:26filcreate