This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: struct: allow per-item byte order
Type: enhancement Stage: resolved
Components: Library (Lib) Versions:
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: mark.dickinson, martin.panter, meador.inge, rhettinger, serhiy.storchaka, zwol
Priority: normal Keywords:

Created on 2016-07-03 16:20 by zwol, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (4)
msg269770 - (view) Author: Zack Weinberg (zwol) * Date: 2016-07-03 16:20
Occasionally one encounters binary formats which do not stick to one byte order throughout.  For example, I have a C program that reads and writes  arrays of this struct:

struct conn_data
  uint32_t ipv4_addr; /* read - network byte order - target IPv4 address */
  uint16_t tcp_port;  /* read - network byte order - target TCP port */
  uint16_t errnm;     /* write - native byte order - errno code */
  uint64_t elapsed;   /* write - native byte order - elapsed time in ns */

On little-endian systems, the first and second fields of this struct will be in the opposite byte order from the third and fourth.

If the struct module allowed specification of byte order on a per-item basis, it would make working with structures of this type simpler.  Hypothetical notation:

addr, port, errnm, elapsed = struct.unpack("=4s!H=H=Q")
addr = socket.inet_ntoa(addr)

instead of what one must do now,

addr, port, errnm, elapsed = struct.unpack("=4sHHQ")
addr = socket.inet_ntoa(addr)
port = socket.ntohs(port)

To avoid ambiguities and confusion, I would suggest that, if more than one item has its own byte-order specifier, _all_ items must have byte-order specifiers (with the possible exception of the 1-byte item types?), and that this is not allowed in an '@'-mode format.
msg290496 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2017-03-25 20:48
This seems too obscure to be worth supporting in the built-in library IMO. The use case loses one line of code but gains a more complicated structure format string.
msg290498 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-03-25 21:05
I concur with Martin.
msg290505 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2017-03-26 05:47
I concur with the other reviewers.  Am going to mark this as closed.

If the need arises, just make multiple struct unpacks.
Date User Action Args
2022-04-11 14:58:33adminsetgithub: 71633
2017-03-26 05:47:51rhettingersetstatus: open -> closed

nosy: + rhettinger
messages: + msg290505

stage: resolved
2017-03-25 21:05:14serhiy.storchakasetnosy: + mark.dickinson, meador.inge, serhiy.storchaka
resolution: rejected
messages: + msg290498
2017-03-25 20:48:25martin.pantersetnosy: + martin.panter
messages: + msg290496
2016-07-03 16:20:09zwolcreate