Mark Dickinson <dicki...@gmail.com> added the comment: 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'. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue3132> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com