Why does '() is ()' return True when '[] is []' and '{} is {}' return False?
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.