Rationale for non-overflow checking format codes in `PyArg_Parse*`

Core Development
1

I was curious if someone knew about the rationale for the ages-old behavior of PyArg_ParseTuple format codes for unsigned integers, none of which checks for overflow (while their signed counterparts do).

For example:

h (int) [short int]
Convert a Python integer to a C short int.
H (int) [unsigned short int]
Convert a Python integer to a C unsigned short int, without overflow checking.

(from Parsing arguments and building values — Python 3.12.0 documentation)

2

Because you do not know whether some integer type alias in C or Posix (like time_t or gid_t) is signed or unsigned. On different platforms it can be different.

Also, when some negative values like -1 can have special meaning, the rest of values can be interpreted as unsigned.