Guido has been strongly opposed to the use of tagged integers:

https://mail.python.org/pipermail/python-dev/2004-July/04614...

IMO, that excuse doesn't hold water on 64 bit machines. On 64 bit machines, not using tagged pointers (using the CPU for fast arithmetic on word sized integers) and instead using the slow branchy sign-magnitude representation that cPython uses for integers is unconscionable, in terms of both performance and memory usage.

this is a post from 16 years ago, and there might be someone who comes around with a solution that resolves his concerns (granted, I feel like it would be hard to come up with a great solution in a language like C, having some ubiquitous unwrapping mechanism + better type checking would make this doable though....)

> this is a post from 16 years ago

Sure, but the only opportunity to change this was along with the other breaking changes in Python 3.0, which is now 12 years old.

It might still be possible to change, by changing the macros that unwrap integers to support tagged integers, then waiting a decade or two before actually starting to use tagged integers. Things that hadn't been recompiled in a decade or two, but were for some reason running the latest interpreter would break. Presumably the number of breakages would be negligible.

This isn't portable C. You can't assume that some pointers will be invalid and free for other uses.

The runtime also controls the alignment of allocations.

You can have a fallback to always use int objects for architectures without that alignment requirement.