Why does ‘() is ()’ return True when ‘[] is []’ and ‘{} is {}’ return False?

by

In short:

Python internally creates a C list of tuple objects whose first element contains the empty tuple. Every time tuple() or () is used, Python will return the existing object contained in the aforementioned C list and not create a new one.

Such mechanism does not exist for dict or list objects which are, on the contrary, recreated from scratch every time.

This is most likely related to the fact that immutable objects (like tuples) cannot be altered and, as such, are guaranteed to not change during execution. This is further solidified when considering that frozenset() is frozenset() returns True; like () an empty frozenset is considered an singleton in the implementation of CPython. With mutable objects, such guarantees are not in place and, as such, there’s no incentive to cache their zero element instances (i.e their contents could change with the identity remaining the same).

Take note: This isn’t something one should depend on, i.e one shouldn’t consider empty tuples to be singletons. No such guarantees are explicitly made in the documentation so one should assume it is implementation dependent.

How it is done:

In the most common case, the implementation of CPython is compiled with two macros PyTuple_MAXFREELIST and PyTuple_MAXSAVESIZE set to positive integers. The positive value for these macros results in the creation of an array of tuple objects with size PyTuple_MAXSAVESIZE.

When PyTuple_New is called with the parameter size == 0 it makes sure to add a new empty tuple to the list if it doesn’t already exist:

if (size == 0) {
    free_list[0] = op;
    ++numfree[0];
    Py_INCREF(op);          /* extra INCREF so that this is never freed */
}

Then, if a new empty tuple is requested, the one that is located in the first position of this list is going to get returned instead of a new instance: 

if (size == 0 && free_list[0]) {
    op = free_list[0];
    Py_INCREF(op);
    /* rest snipped for brevity.. */

One additional reason causing an incentive to do this is the fact that function calls construct a tuple to hold the positional arguments that are going to be used. This can be seen in the load_args function in ceval.c:

static PyObject *
load_args(PyObject ***pp_stack, int na)
{
    PyObject *args = PyTuple_New(na);
    /* rest snipped for brevity.. */

which is called via do_call in the same file. If the number of arguments na is zero, an empty tuple is going to be returned.

In essence, this might be an operation that’s performed frequently so it makes sense to not reconstruct an empty tuple every single time.

Further reading:

A couple more answers shed light on CPython‘s caching behaviour with immutables:

  • For integers, another answer that digs in the source can be found here.
  • For strings, a handful of answers can be found here, here and here.

Leave a Comment

tech