Packing errors using struct in 3.9 seem to be unnecessarily obfuscated to me.

    >>> import struct
    >>> struct.pack('H', 70000)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    struct.error: ushort format requires 0 <= number <= (0x7fff * 2 + 1)

Why "0x7fff * 2 + 1"? Why not the more straightforward "0xffff" or 65536? (I have a slight preference for hex.)

Compare that to:

    >>> struct.pack('I', 4300000000)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    struct.error: 'I' format requires 0 <= number <= 4294967295

which at least gives the actual value, but it would perhaps be a bit more useful in hex 0xffffffff.

For the long-long format, the error message just gives up:

    >>> struct.pack('Q', 2**65)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    struct.error: argument out of range

Could be improved by:

'Q' format requires 0 <= number <= 0xffff_ffff_ffff_ffff

I agree, including use of hex, if possible, for unsigned (non-negative) values.

Grepping 'format requires' returns
F:\dev\3x\Modules\_struct.c: 365:             "'%c' format requires 0 <= number <= %zu",
F:\dev\3x\Modules\_struct.c: 371:             "'%c' format requires %zd <= number <= %zd",
F:\dev\3x\Modules\_struct.c: 550:                         "byte format requires -128 <= number <= 127");
F:\dev\3x\Modules\_struct.c: 565:                         "ubyte format requires 0 <= number <= 255");
F:\dev\3x\Modules\_struct.c: 577:                         "char format requires a bytes object of length 1");
F:\dev\3x\Modules\_struct.c: 593:                         "short format requires " Py_STRINGIFY(SHRT_MIN)
F:\dev\3x\Modules\_struct.c: 611:                         "ushort format requires 0 <= number <= "
                                                           Py_STRINGIFY(USHRT_MAX));

I believe l365 is the source for the 2nd example. AFAIK, 'zu' is not valid for either C printf or Python % formating.
Lines 611 and 612 are the source for the 1st example. From comments before line 365, there can be issues with lefts shifts, but '0xffff', '0xffff_ffff', and '0xffff_ffff_ffff_ffff' could be hard-coded strings that would cover all 'normal' systems.

Grepping "argument out of range" returns
F:\dev\3x\Modules\_struct.c: 168: "argument out of range");
F:\dev\3x\Modules\_struct.c: 192: "argument out of range");
F:\dev\3x\Modules\_struct.c: 215: "argument out of range");
F:\dev\3x\Modules\_struct.c: 238: "argument out of range");
F:\dev\3x\Modules\_struct.c: 261: "argument out of range");
F:\dev\3x\Modules\_struct.c: 284: "argument out of range");

It is nnclear to me without more reading why some codes lead to this less helpful message.

I would like to work on this if nobody else has already started :)

Go ahead, with the understanding that there is no guaranteed acceptance of the change, even with a good patch. There may be reasons for the status quo that neither Steven nor I are aware of. I don't think that either of the listed experts, added as nosy, are very active. In any case, revised or new tests will be needed.

New changeset 8ca6b61 by Nikita Sobolev in branch 'main':
bpo-45034: Fix how upper limit is formatted for struct.pack("H", ...) (GH-28178)
8ca6b61

The out-of-range error messages for unsigned short and short have been fixed, thanks to Nikita Sobolev. They resulted from a rather odd use of the Py_STRINGIFY macro, which meant that not only were the messages obscure, but they differed from system to system: e.g., on my machine I get: "struct.error: ushort format requires 0 <= number <= (32767 *2 +1)", and "struct.error: short format requires (-32767 -1) <= number <= 32767", complete with the weird spacing.

There's still room for normalising the other messages and/or converting the limits to hex if anyone wants to provide a PR.

I'm unsure about using hex universally: while 0xffffffffffffffff (or even better, 0xffff_ffff_ffff_ffff) is definitely more useful than 18446744073709551615, I think I'd still find -128 more immediately readable than -0x80.

@mdickinson @sobolevn The issue seems to be solved. We can close the issue.

@furkanonder Thanks for the ping. Indeed I think the changes in #98252 mean this issue can be closed.