You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Drop support for platforms without two's complement integer representation: require two's complement to build Python #100008
Only very old machines (built in the 1960s?) like UNIVAC 1100/2200 series use signed number representations different than two's complement. Nowadays, all CPUs use the two's complement representation and CPython code base already relies on that in many places (especially Objects/longobject.c). For example, Python adds the -fwrapv compiler flag to GCC and clang.
The signed parameter of int.from_bytes() and int.to_bytes() indicates whether two's complement is used to represent the integer.
I propose to be more explicit on build requirements for integers:
Two's complement
No trap representation
No padding bits
Mark Dickinson @mdickinson likes to repeat that CPython has these requirements :-)
I think the -(x + 1) pattern came from days when we worried too much about alternative integer representations allowed by the C spec (sign-magnitude, ones' complement, two's complement with a trap representation, etc.). But since then other parts of the codebase have been happy to assume that all integer types are two's complement, no padding bits, no trap representation, so I think it's safe to do so here. (And your changes to the other bitwise operations already assume two's complement and no trap representation.)
(...) But making all our usual assumptions about integer representation (two's complement, no trap representation, no padding bits, etc.), -INT_MIN-1 is the same as INT_MAX (...)
I created this issue while reviewing PR #99762 which proposes to generalize a micro-optimization relying on a cast from an signed integer to an unsigned integer: replace 0 <= index && index < limit (Py_ssize_t) with (size_t)index < (size_t)limit. I'm not sure that two's complement is strictly required for this micro-optimization, but it reminded it to me :-)
Activity
vstinner commentedon Dec 5, 2022
See also issue gh-91073 which required IEEE 754 support in Python 3.11.
gh-100008: Document Python build requirements (#100009)
vstinner commentedon Dec 5, 2022
Article about that: https://trust-in-soft.com/blog/2016/06/16/trap-representations-and-padding-bits/
The _Bool type caused trouble with trap values in the past in the struct module. See the issue gh-83870:
Lib/test/test_buffer.py still contains the skip:
vstinner commentedon Dec 5, 2022
A first shy PR which only requires two's complement, without mentioning trap representation or padding: PR #100014.
vstinner commentedon Dec 5, 2022
In 2018, N2218: Signed Integers are Two’s Complement was proposed for the C language:
I don't know the status of this spec: see P0907R4.
gh-100008: VS 2017 is required since Python 3.11 (#100045)
vstinner commentedon Dec 9, 2022
See PR #100064 which casts a signed integer to an unsigned integer to test
0 <= value < limitas a single(size_t)value < limitoperation.