In Python, integers have arbitrary magnitude. You need not worry about how many bits are used in memory to store the integer; integers can be arbitrarily large (or large negative).

In this case, the 224 bits you are seeing are not all used to represent the integer; a lot of that is overhead of representing a Python object (as opposed to a native value in C-like languages).

EDIT: See also: https://docs.python.org/3/library/stdtypes.html#typesnumeric

The short answer

You're getting the size of the class, not of an instance of the class. Call int to get the size of an instance:

>>> sys.getsizeof(int())
28

If that size still seems a little bit large, remember that a Python int is very different from an int in (for example) C. In Python, an int is a fully-fledged object. This means there's extra overhead.

Every Python object contains at least a refcount and a reference to the object's type in addition to other storage; on a 64-bit machine, just those two things alone take up 16 bytes! The int internals (as determined by the standard CPython implementation) have also changed over time, so that the amount of additional storage taken depends on your version.

int objects in CPython 3.11

Integer objects are internally PyLongObject C types representing blocks of memory. The code that defines this type is spread across multiple files. Here are the relevant parts:

typedef struct _longobject PyLongObject;

struct _longobject {
    PyObject_VAR_HEAD
    digit ob_digit[1];
};

#define PyObject_VAR_HEAD      PyVarObject ob_base;

typedef struct {
    PyObject ob_base;
    Py_ssize_t ob_size; /* Number of items in variable part */
} PyVarObject;

typedef struct _object PyObject;

struct _object {
    _PyObject_HEAD_EXTRA
    union {
       Py_ssize_t ob_refcnt;
#if SIZEOF_VOID_P > 4
       PY_UINT32_T ob_refcnt_split[2];
#endif
    };
    PyTypeObject *ob_type;
};

/* _PyObject_HEAD_EXTRA is nothing on non-debug builds */
#  define _PyObject_HEAD_EXTRA

typedef uint32_t digit;

If we expand all the macros and replace all the typedef statements, this is the struct we end up with:

struct PyLongObject {
    Py_ssize_t ob_refcnt;
    PyTypeObject *ob_type;
    Py_ssize_t ob_size; /* Number of items in variable part */
    uint32_t ob_digit[1];
};

uint32_t means "unsigned 32-bit integer" and uint32_t ob_digit[1]; means an array of 32-bit integers is used to hold the (absolute) value of the integer. The "1" in "ob_digit[1]" means the array should be initialized with space for 1 element.

So we have the following bytes to store an integer object in Python (on a 64-bit system):

• 8 bytes (64 bits, Py_ssize_t, signed) for ob_refcnt - the reference count
• 8 bytes (64 bits, PyTypeObject*) for ob_type - the pointer to the int class itself
• 8 bytes (64 bits, Py_ssize_t, signed) for ob_size - which stores how many 32-bit integers are used to store the integer

and finally a variable-length array (with at least 1 element) of

• 4 bytes (32 bits) to store each part of the integer

The comment that accompanies this definition summarizes Python 3.11's representation of integers. Zero is represented not by an object with size (ob_size) zero (the actual size is always at least 1 though). Negative numbers are represented by objects with a negative size attribute! This comment further explains that only 30 bits of each uint32_t are used for storing the value.

>>> sys.getsizeof(0)
28
>>> sys.getsizeof(1)
28
>>> sys.getsizeof(2 ** 30 - 1)
28
>>> sys.getsizeof(2 ** 30)
32
>>> sys.getsizeof(2 ** 60 - 1)
32
>>> sys.getsizeof(2 ** 60)
36

On CPython 3.10 and older, sys.getsizeof(0) incorrectly returns 24 instead of 28, this was a bug that was fixed. Python 2 had a second, separate type of integer which worked a bit differently, but generally similar.

You will get slightly different results on a 32-bit system.

Python can handle arbitrary int sizes. The error you have indicates that python is trying to malloc more memory, but failed. You probably have a memory leak somewhere.

int and long were "unified" a few versions back. Before that it was possible to overflow an int through math ops.

3.x has further advanced this by eliminating long altogether and only having int.

• Python 2: sys.maxint contains the maximum value a Python int can hold.
  • On a 64-bit Python 2.7, the size is 24 bytes. Check with sys.getsizeof().
• Python 3: sys.maxsize contains the maximum size in bytes a Python int can be.
  • This will be gigabytes in 32 bits, and exabytes in 64 bits.
  • Such a large int would have a value similar to 8 to the power of sys.maxsize.

def byte_length(i):
    return (i.bit_length() + 7) // 8

Of course, as Jon Clements points out, this isn't the size of the actual PyIntObject, which has a PyObject header, and stores the value as a bignum in whatever way is easiest to deal with rather than most compact, and which you have to have at least one pointer (4 or 8 bytes) to on top of the actual object, and so on.

But this is the byte length of the number itself. It's almost certainly the most efficient answer, and probably also the easiest to read.

Or is ceil(i.bit_length() / 8.0) more readable?