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?

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.

The allocation unit cannot be smaller that 1 byte. For a 1-bit variable (a Boolean value) you have to allocate at least 8 bits, 7 of them unused.

A modern CPU operates on 64 bits (8 bytes), some on 32 bits = 4 bytes; 16-bit embedded controllers are common, 8-bit controllers are already rare. RAM also works more efficiently with larger widths, and normally expects alignment on 4-byte border for efficient fetches. This is why a 1-bit value can even take up 4 bytes in memory.

A Python integer is an object. Yes, you can invoke methods right on an integer constant: (1).__add__(2) or (100).bit_length(). This means that the actual integer value is stored along with a lot of other information.

Python integers try to adapt to the size of data, more so in Python 3 were an integer of any length is an object of the same type, just allocating enough bytes to store the value.

You can indeed pack values of small magnitude to more efficiently use the bits available. This is common is storage formats, especially where bandwidth is important. E.g. a GPU can work with textures packed in various ways, both as integers and (short) floats. Most modern CPUs have "vector instructions" to work with several independent 16-bit and 8-bit integers packed into 32- or 64-bit registers.