Jim Jim - 4 months ago 10
Python Question

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

From what I've been aware of, using

[], {}, ()
to instantiate objects returns a new instance of
list, dict, tuple
respectively; a new instance object with a new identity*.

This was pretty clear to me until I actually tested it where I noticed that
() is ()
actually returns
False
instead of the expected
True
:

>>> () is (), [] is [], {} is {}
(True, False, False)


and, as expected, this behavior is also manifested when explicitly creating objects with
list()
,
dict()
and
tuple()
:

>>> tuple() is tuple(), list() is list(), dict() is dict()
(True, False, False)


The only relevant piece of information I could find in the docs for
tuple()
states:


[...] For example,
tuple('abc')
returns
('a', 'b', 'c')
and
tuple([1, 2, 3])
returns
(1, 2, 3)
. If no argument is given, the constructor creates a new empty tuple,
()
.



Suffice to say, this isn't sufficient for answering my question.

So, why do empty tuples have the same identity whilst others like lists or dictionaries do not?




*Note, this question is not about what the
is
operator does, as explained in Understanding Python's “is” operator, but rather, why it behaves as it does in this specific case.

Jim Jim
Answer

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.

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 related reading:

A couple more answers portray CPython's caching behaviour with immutables:

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