Return to Answer

Byte: 0123
Value: 0x12 0x34 0x56 0x78

Now, back to our problem(s): as stated above, 5 is 0x05 (or 0x00000005 - 4 byte unsigned int) or in chars: "\x00\x00\x00\x05". But it's in reversed order than what struct.pack displays; I think you already guessed why: it's in little endian representation. That is given by the 1^st (fmt) argument ("<" part to be more precise) given to [Python 2.Docs]: struct.pack(fmt, v1, v2, ...) (possible values are listed on the same page: [Python 2.Docs]: struct - Byte Order, Size, and Alignment). For 55555, things are just the same. Its hex representation is: 0xd903 or 0x0000d903.

╔═══════════╦══════════╦══════════╦══════════╦══════════╗

║ Byte ║ 01 ║ 02 ║ 03 ║ 04 ║
╠═══════════╬══════════╬══════════╬══════════╬══════════╣
║ Value ║ 0x12 ║ 0x34 ║ 0x56 ║ 0x78 ║
╚═══════════╩══════════╩══════════╩══════════╩══════════╝

Now, back to our problem(s): as stated above, 5 is 0x05 (or 0x00000005 - 4 byte unsigned int) or in chars: "\x00\x00\x00\x05". But it's in reversed order than what struct.pack displays; I think you already guessed why: it's in little endian representation. That is given by the 1^st (fmt) argument ("<" part to be more precise) given to [Python 2.Docs]: struct.pack(fmt, v1, v2, ...) (possible values are listed on the same page: [Python 2.Docs]: struct - Byte Order, Size, and Alignment). For 55555, things are just the same. Its hex representation is: 0xd903 or 0x0000d903.

From [Python 2]: struct - Interpret bytes as packed binary data:

Before going further, a few words are needed about endianness: that is the way how data (numbers in our case) is represented in computer memory. A couple of links:

• [UMD.CS]: Big and Little Endian
• [Wikipedia]: Endianness

Now, back to our problem(s): as stated above, 5 is 0x05 (or 0x00000005 - 4 byte unsigned int) or in chars: "\x00\x00\x00\x05". But it's in reversed order than what struct.pack displays; I think you already guessed why: it's in little endian representation. That is given by the 1^st (fmt) argument ("<" part to be more precise) given to [Python 2]: struct.pack (possible values are listed on the same page: [Python 2]: Byte Order, Size, and Alignment). For 55555, things are just the same. Its hex representation is: 0xd903 or 0x0000d903.

import struct
fmt = "<L"
data_set = [5, 55555, 0x12345678]
for data in data_set:
 output_str = "{} - {}".format(hex(data), repr(struct.pack(fmt, data)).strip("'")) # This is just for formatting output string to be displayed to the user
 print(output_str) # Python3 compatible (however the formatting above won't behave nicely)

c:\Work\Dev\StackOverflow\q037990060>"C:\Install\x64\HPE\OPSWpython2円.7.10__00\python.exe" "code.py"

0x5 - \x05\x00\x00\x00
0xd903 - \x03\xd9\x00\x00
0x12345678 - xV4\x12

From [Python 2.Docs]: struct - Interpret bytes as packed binary data:

Before going further, a few words are needed about endianness: that is the way how data (numbers in our case) is represented in computer memory. A couple of links (although many resources can be found on the internet):

• [Wikipedia]: Endianness
• [UMD.CS]: Big and Little Endian

Now, back to our problem(s): as stated above, 5 is 0x05 (or 0x00000005 - 4 byte unsigned int) or in chars: "\x00\x00\x00\x05". But it's in reversed order than what struct.pack displays; I think you already guessed why: it's in little endian representation. That is given by the 1^st (fmt) argument ("<" part to be more precise) given to [Python 2.Docs]: struct.pack(fmt, v1, v2, ...) (possible values are listed on the same page: [Python 2.Docs]: struct - Byte Order, Size, and Alignment). For 55555, things are just the same. Its hex representation is: 0xd903 or 0x0000d903.

import struct
fmt = "<L"
data_set = [5, 55555, 0x12345678]
for data in data_set:
 output_str = "{} - {}".format(hex(data), repr(struct.pack(fmt, data)).strip("'")) # This is just for formatting output string to be displayed to the user
 print(output_str) # Python3 compatible (however the formatting above won't behave nicely)

c:\Work\Dev\StackOverflow\q037990060>"C:\Install\x64\HPE\OPSWpython2円.7.10__00\python.exe" "code.py"

0x5 - \x05\x00\x00\x00
0xd903 - \x03\xd9\x00\x00
0x12345678 - xV4\x12

This means that it will print the memory representation of the argument(s) as char sequences. Memory (and everything that resides in it) is a sequence of bytes. Each byte has a value [0..255] (for simplicity's sake I use unsigned).
So, when it will represent a byte, it will first search for a char having the ASCII code matching the byte value, and if such a (printable) char is found, it will be the representation of that byte, otherwise the representation will be the byte value (in hex) preceded by \x (convention for representing non printable chars). As a side note, (non extended) ASCII chars have values between 0 and 128.

Now, back to our problem(s): as stated above, 5 is 0x05 (or 0x00000005 - 4 byte unsigned int) or in chars: \x00\x00\x00\x05. But it's in reversed order than what struct.pack displays; I think you already guessed why: it's in little endian representation. That is given by the 1^st (fmt) argument (the "<" part to be more precise) given to [Python 2]: struct.pack (possible values are listed on the same page: [Python 2]: Byte Order, Size, and Alignment). For 55555, things are just the same. Its hex representation is: 0xd903 or 0x0000d903.

This means that it will print the memory representation of the argument(s) as char sequences. Memory (and everything that resides in it) is a sequence of bytes. Each byte has a value [0..255] (for simplicity's sake I use unsigned).
So, when it will represent a byte, it will first search for a char having the ASCII code matching the byte value, and if such a (printable) char is found, it will be the representation of that byte, otherwise the representation will be the byte value (in hex) preceded by \x (convention for representing non printable chars). As a side note, (non extended) ASCII chars have values between 0 and 128.

Now, back to our problem(s): as stated above, 5 is 0x05 (or 0x00000005 - 4 byte unsigned int) or in chars: "\x00\x00\x00\x05". But it's in reversed order than what struct.pack displays; I think you already guessed why: it's in little endian representation. That is given by the 1^st (fmt) argument ("<" part to be more precise) given to [Python 2]: struct.pack (possible values are listed on the same page: [Python 2]: Byte Order, Size, and Alignment). For 55555, things are just the same. Its hex representation is: 0xd903 or 0x0000d903.