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