After a bit more thought (and after soliciting a couple of opinions on #python-dev), I'm convinced that endianness changes within a substruct should be local to that substruct:

- it makes the meaning of '>2T{H<H}' both unsurprising and easy to understand:  i.e., it would be interpreted exactly as '>T{H<H}T{H<H}', and  both substructs would behave like '>H<H'.

- I suspect it's the behaviour that people expect

- it may make dynamic creation of struct format strings easier/less bug-prone.


But now I've got a new open issue:  how much padding should be inserted/expected (for pack/unpack respectively) between the 'B' and the 'T{...}' in a struct format string of the form 'BT{...}'?

For this, I don't think we can hope to exactly comply with the platform ABI in all cases.  But I think there's a simple rule that would work 99% of the time, and that does match the ABI on common platforms (though I'll check this), namely that the alignment requirement of the 'T{...}' struct should be the least common multiple of the alignment requirements of any of its elements.  (Which will usually translate to the largest of the alignment requirements, since those alignments are usually all going to be powers of 2.)

And *this* is where things get tricky if the alignment/byteorder/size specifier is changed midstream, since then it doesn't seem clear what alignments would contribute to the lcm above.  I'm tempted to suggest that for native mode, changing the specifier be disallowed entirely.

Travis, any comments on any of this?