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 Alexander.Belopolsky, MrJean1, ajaksu2, barry, benjamin.peterson, inducer, mark.dickinson, meador.inge, noufal, pitrou, teoliphant
Date 2010-05-20.14:26:13
SpamBayes Score 0.000590832
Marked as misclassified No
Message-id <>
Thanks for the new patch.

> "... If un-aligned, native data-types are requested, then the
> endian specification is '^'."
> However, I am not quite sure how to interpret the last sentence.

Hmm.  Seems like the PEP authors are proposing a new byteorder/alignment/size specifier here:  '^' = native byte-order + native size + no alignment.  I missed this before.

>> Should the switch to '>' within the embedded struct be regarded as 
>> local to the struct?

>No, there is no notion of scope here.  A given specifier is active >until the next one is found.

Okay.  I wonder whether that's the most useful thing to do, though.

As a separate issue, I notice that the new 'T{}' code doesn't respect multiplicities, e.g., as in 'H3T{HHL}'.  Is that intentional/desirable?

>>> struct.pack('H3T{HHL}', 1, (2, 3, 4))

If we don't allow multiplicities, this should produce an exception, I think.  If we do allow multiplicities (and I don't immediately see why we shouldn't), then we're going to have to be clear about how endianness behaves in something like:


So the first inner struct here would be treated as '{>H<H}'.  Would the next two be identical to this, or would they be as though the whole thing were '>HT{H<H}T{H<H}T{H<H}', in which case the 2nd and 3rd substructs are both effectively '<H<H', while the first is '>H<H'.
Date User Action Args
2010-05-20 14:26:16mark.dickinsonsetrecipients: + mark.dickinson, barry, teoliphant, pitrou, inducer, ajaksu2, MrJean1, benjamin.peterson, noufal, meador.inge, Alexander.Belopolsky
2010-05-20 14:26:15mark.dickinsonsetmessageid: <>
2010-05-20 14:26:13mark.dickinsonlinkissue3132 messages
2010-05-20 14:26:13mark.dickinsoncreate