Mark Dickinson <[email protected]> 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 <[email protected]>
<http://bugs.python.org/issue3132>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
