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'.