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 <1274365575.97.0.300011969331.issue3132@psf.upfronthosting.co.za>
In-reply-to
Content
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))
b'\x01\x00\x02\x00\x03\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00'

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:

'>H3T{H<H}'

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'.
History
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: <1274365575.97.0.300011969331.issue3132@psf.upfronthosting.co.za>
2010-05-20 14:26:13mark.dickinsonlinkissue3132 messages
2010-05-20 14:26:13mark.dickinsoncreate