In a dynamically-typed language, the code can never know in advance what will be the type of any variable. You can define a function to perform a particular operation on, say, a collection, but unless you explicitly filter out an argument that is not a collection, the code is never certain that it is indeed one – and the bytecode compiler sure cannot be certain either.

Using dynamic types has consequences for the language – both from a conceptual standpoint and from an implementation standpoint.

Conceptual consequences

From a conceptual perspective, dynamically-typed languages care more about the attributes and methods supported by an object than its actual type. This is the concept of duck typing: if it quacks like a duck then we consider it’s a duck – whether or not it is actually a duck.

An example of duck typing in statically-typed languages would be Java interfaces. When a Java class implements an interface, it needs to implement certain methods. Once it does, a program can use this class without knowing -nor caring about- its actual type. The difference of course is that this type is statically defined, and the Java compiler will not let you compile your code unless your classes implement all the methods required by the interfaces they use.

Duck typing has however its downsides. Namely, it forces to give details about the implementation. Consider the case where we want to create a function “double”:

def double(elt):
    return elt + elt

So far, so good. This function may have been designed with numbers in mind, but it does work with other types such as strings. Heck, it can work with any type that defines an __add__ method. And that is where lies the problem: one needs to have some detail about the underlying implementation of double(). What if we change later on that implementation for something like:

def double(elt):
    return 2 * elt

Will it work for all my use of double()? For types like numbers or strings, sure. But for other types, who knows…

Implementation consequences

From an implementation standpoint, Python needs to be able to dynamically check whether a given object has a specific attribute or function. Even in the case of CPython where the code is being compiled into bytecode on the fly, there is only so much the compiler can do. The bytecode instruction that is involved here is LOAD_ATTR whose job is to determine at runtime whether the object has the desired attribute and push it onto the stack if it exists (as previously shown, a method is just an attribute of type function). Since an object in Python is really a map from strings to values, the logical implementation choice for such a lookup is a dictionary⁽¹⁾.

I do not know if this is a result of using dictionaries for attribute lookup or the cause, but dynamically-typed languages typically allow to add new attributes to existing objects and define new methods to already defined classes – something that can be easily implemented when you are already using a dictionary to map attribute values.

To recap:

• Because two different instances of the same class can have completely different attributes, they must each have a dictionary containing all their attributes and their values.
• If two different instances of the same class inherit the same attributes/methods from it, one can nonetheless define new class attributes/methods on the fly. Which means that each class needs to have its own attribute dictionary.

This is a stark contrast with statically-typed languages where a compiler knows exactly what attribute or method needs to be called. In a language such as C++, objects are pretty much an array of attributes. All the instance of the same class have the exact same size. The C++ compiler knows exactly where will the attribute be in memory (e.g. at offset 8 from the beginning of the object). Likewise, it knows exactly what method is being called by every line of code⁽²⁾.

Dynamic typing thus has an impact on performance as CPython must 1) use a dictionary lookup each time an attribute needs to be accessed and 2) perform that lookup at runtime.

Attribute lookup and object inheritance

Object inheritance is even complexifying attribute lookup. Indeed, the runtime may need to check for an attribute in the class object and any parent class. As a general rule though, Python will return the attribute value from the object dictionary if there is any. If there isn’t, it will return the result from a class attribute lookup following the Method Resolution Order (MRO).

Let’s consider the following code:

>>> class MyClass1(object):
...     attr1 = 1
...     attr2 = 2
...
>>> class MyClass2(MyClass1):
...     attr2 = 3
...
>>> obj = MyClass2()
>>> obj.attr1            # MyClass1.attr1
1
>>> MyClass1.attr2 = 42
>>> MyClass1.attr3 = 43
>>> obj.attr3            # MyClass1.attr3
43
>>> obj.attr2            # MyClass2.attr2
3
>>> obj.attr2 = 44       # obj.attr2

As you can see, you can dynamically add new attributes in MyClass1 (line 12) and it will be automatically be reflected in the object (lines 13, 14). You can this way define a new class method by adding a lambda function as a class attribute. Updating “MyClass1.attr2” doesn’t however affect “obj” (lines 15, 16) as MyClass2 is overwriting it (line 6). However, you can overwrite any class attribute in the object itself (line 17)

You can see the result when looking at the dictionaries of the various objects and classes involved. The object dictionary contains the value that it defined at line 17. MyClass2’s dictionary contains the values for “attr2” it set in its class definition. And MyClass1’s dictionary contains the values for “attr1” (set at line 2), “attr2” and “attr3” (set at lines 11 and 12):

>>> obj.__dict__
{'attr2': 44}
>>> MyClass2.__dict__
mappingproxy({'__module__': '__main__', 'attr2': 3, '__doc__': None})
>>> MyClass1.__dict__
mappingproxy({'__module__': '__main__',
'attr3': 43, 'attr2': 42, 'attr1': 1,
'__dict__': <attribute '__dict__' of 'MyClass1' objects>,
'__weakref__': <attribute '__weakref__' of 'MyClass1' objects>,
'__doc__': None})

Note that the MRO here is pretty simple. It is a bit more complex when using mixins. In any case, a class “__mro__” attribute tells what classes to look at and in what order:

>>> MyClass2.__mro__
(<class '__main__.MyClass2'>, <class '__main__.MyClass1'>, <class 'object'>)

Last but not least, dir(obj) gives all the attributes visible for “obj”. This includes the attributes declared in “obj” as well as those declared in MyClass1 and MyClass2:

>>> dir(obj)
['__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__',
 '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__',
 '__le__', '__lt__', '__module__', '__ne__', '__new__', '__reduce__',
 '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__',
 '__subclasshook__', '__weakref__', 'attr1', 'attr2', 'attr3']

(1) This is not always the case. V8, the JavaScript engine used in Chrome and Node.js, is sometimes using the concept of hidden class and can represent objects as an array of values, avoiding costly dictionary lookups.

(2) A notable exception is virtual functions, where the C++ compiler has no way of knowing what actual method will be called at runtime. But even in this case, the way the C++ runtime gets around it (virtual tables) is pretty efficient and does not involves a dictionary lookup.

>>> type(1)
<class 'int'>
>>> type('test')
<class 'str'>
>>> type('test'.__str__)
<class 'method-wrapper'>
>>> def func():
...     pass
...
>>> type(func)
<class 'function'>
>>>
>>> class MyClass(object):
...     pass
...
>>> obj = MyClass()
>>> type(MyClass)
<class 'type'>
>>> type(obj)
<class '__main__.MyClass'>
>>> type(None)
<class 'NoneType'>

Python is using a pure object model where classes are instances of a meta-class “type” (in Python, the terms “type” and “class” are synonyms). And “type” is the only class which is an instance of itself:

>>> type(42)
<class 'int'>
>>> type(int)    # same as type(type(42))
<class 'type'>
>>> type(type)   # same as type(type(type(42)))
<class 'type'>

This object model can be useful when we want information about a particular resource in Python. Except for the Python keywords (e.g. if, def, globals), using “type(<name>)” or “dir(<name>)” -or just type the resource name and press enter- will work on pretty much anything.

>>> super
<class 'super'>
>>> abs
<built-in function abs>
>>> str
<class 'str'>
>>> dir
<built-in function dir>

Objects, methods and attributes

Objects can have methods and attributes. Let’s look how the two differ by looking at the following code and the disassembled code behind method2():

>>> class MyClass(object):
...     attr = 42
...     def method1(self):
...             pass
...     def method2(self):
...             self.method1()
...             return self.attr
...
>>> dis.dis(MyClass.method2)
  6           0 LOAD_FAST                0 (self)
              3 LOAD_ATTR                0 (method1)
              6 CALL_FUNCTION            0 (0 positional, 0 keyword pair)
              9 POP_TOP

  7          10 LOAD_FAST                0 (self)
             13 LOAD_ATTR                1 (attr)
             16 RETURN_VALUE

The only difference between “self.method1()” and “self.attr” is just the CALL_FUNCTION which is just telling the CPython runtime to execute a function based on what is on the stack. But from an object perspective, a method is just an attribute whose type is “method” or “method-wrapper”⁽¹⁾. You can actually allow a function call by defining __call__ on the attribute:

>>> class Attr(object):
...     value = 42
...
>>> class MyClass(object):
...     attr = Attr()
...
>>> obj = MyClass()
>>> Attr.__call__ = lambda self : self.value
>>> obj.attr.value
42
>>> obj.attr()
42

In the above example we did not even define __call__ inside the Attr class definition but afterwards, by just adding a class attribute which is a lambda function. The method however needs to have a “self” argument, otherwise it needs to be applied to the class (static method) and not to an instance.

To take another example, “type(42)” is not a call to a built-in function like “dir(42)”, but is the same as “type.__call__(type, 42)”. In other words we’re calling the __call__ method for the class “type” and pass as argument the instance “type” (self) and the object 42⁽²⁾.

The fact that methods are just a special type of attribute helps explain why the function dir() returns a list of all the combined attributes and methods for a given object:

>>> class MyClass(object):
...     attr = 42
...     def test(self):
...             pass
...
>>> dir(obj)
['__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__',
 '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__',
 '__module__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__',
 '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__',
 'attr', 'test']

You can see that the last two element in the array are the “attr” attribute and the “test” method as defined in the class. For the rest, all the other attributes take the __<name>__ notation which is used to represent descriptors. Descriptors are object attributes with binding behavior. For example, obj.__dir__() is called under the hood by dir(obj). Likewise, __le__ is a method that can be overridden in MyClass to implement obj1 <= obj2.

Yes, number literals too

One could think that number literals do not behave like regular objects. Even though dir(42) shows a method __add__, trying to call 42.__add__ fails:

>>> 42.__add__(4)
  File "<stdin>", line 1
    42.__add__(4)
             ^
SyntaxError: invalid syntax

But the error has to do with parsing and not how the object 42 behaves. Python indeed interprets the first three characters (“42.”) as a float, and as a result does not understand what to do with “__add__”. You can however call the method on 42 by using a few tricks:

>>> 42 .__add__(4)   # inserting a space after 42
46
>>> (42).__add__(4)  # wrapping 42 inside ()
46
>>> 42..__add__(4)   # using 42.0 instead of 42
46.0

Implementation under the hood

Let’s now dive in the C implementation to see how are objects represented.

Those objects are manipulated under the hood as a C structure called PyObject. Ironically, the CPython object model is implemented using C, a language which is not object-oriented.

typedef struct _object {
    _PyObject_HEAD_EXTRA
    Py_ssize_t ob_refcnt;
    struct _typeobject *ob_type;
} PyObject;

You will notice the two following attributes:

• a reference count, which keeps track of how many other objects and variables reference it. This is changed in the C code through the macros Py_INCREF() and Py_DECREF()
• a type (PyTypeObject structure), which allows Python to determine the type (aka class) of the object at runtime. That type contains various methods which are used to describe the behavior of the class. What function to call to allocate the type, to deallocate the type, to cast as a number, etc.

Built-in types vs user class

Python comes with some built-in classes, such as int, str, list, but also function or class.

Contrary to a language such as Ruby where everything is also an object, Python does not allow to add new attributes or methods to the built-in types such as int or str, let alone redefine existing methods:

>>> number = 10
>>> number.attr = 10
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'int' object has no attribute 'attr'

The declarations of these objects are in the Include directory, and you can find in Object the various implementations of several types: int (Objects/longobject.c), str (Objects/unicodeobject.c), list (Objects/listobject.c), user-defined classes (Objects/classobject.c), functions (Objects/funcobject.c), etc.

Each of those files defines a PyTypeObject instance which represents the type. Each PyTypeObject instance contains mostly functions that describe the behavior of the type. For example, tp_getattro and tp_setattro, when defined, are the functions that allow to respectively read and assign a value to an attribute. The absence of tp_setattro for the “int” type explains why it is not possible to add or change an attribute to an integer. tp_as_sequence and tp_as_mapping point to lists of methods to handle standard functions for respectively functions and dictionaries.

PyTypeObject PyLong_Type = {
    PyVarObject_HEAD_INIT(&PyType_Type, 0)
    "int",                                      /* tp_name */
    offsetof(PyLongObject, ob_digit),           /* tp_basicsize */
    sizeof(digit),                              /* tp_itemsize */
    long_dealloc,                               /* tp_dealloc */
    0,                                          /* tp_print */
    0,                                          /* tp_getattr */
    0,                                          /* tp_setattr */
    0,                                          /* tp_reserved */
    long_to_decimal_string,                     /* tp_repr */
    &long_as_number,                            /* tp_as_number */
    0,                                          /* tp_as_sequence */
    0,                                          /* tp_as_mapping */
    (hashfunc)long_hash,                        /* tp_hash */
    0,                                          /* tp_call */
    long_to_decimal_string,                     /* tp_str */
    PyObject_GenericGetAttr,                    /* tp_getattro */
    0,                                          /* tp_setattro */
    0,                                          /* tp_as_buffer */
    Py_TPFLAGS_DEFAULT | Py_TPFLAGS_BASETYPE |
        Py_TPFLAGS_LONG_SUBCLASS,               /* tp_flags */
    long_doc,                                   /* tp_doc */
    0,                                          /* tp_traverse */
    0,                                          /* tp_clear */
    long_richcompare,                           /* tp_richcompare */
    0,                                          /* tp_weaklistoffset */
    0,                                          /* tp_iter */
    0,                                          /* tp_iternext */
    long_methods,                               /* tp_methods */
    0,                                          /* tp_members */
    long_getset,                                /* tp_getset */
    0,                                          /* tp_base */
    0,                                          /* tp_dict */
    0,                                          /* tp_descr_get */
    0,                                          /* tp_descr_set */
    0,                                          /* tp_dictoffset */
    0,                                          /* tp_init */
    0,                                          /* tp_alloc */
    long_new,                                   /* tp_new */
    PyObject_Del,                               /* tp_free */
};

User types

When the program is defining a user class, the runtime creates a new type for that class. Here is an example of such a type inside the C debugger:

(gdb) print *tp
$67 = {ob_base = {ob_base = {_ob_next = 0x98a6034, _ob_prev = 0x98a3058, ob_refcnt = 6,
      ob_type = 0x82a9d60}, ob_size = 0},
  tp_name = 0x98a3070 "MyClass",
  tp_basicsize = 24,
  tp_itemsize = 0,
  tp_dealloc = 0x8073ac6 <subtype_dealloc>,
  tp_print = 0,
  tp_getattr = 0,
  tp_setattr = 0,
  tp_reserved = 0x0,
  tp_repr = 0x8078847 <object_repr>,
  tp_as_number = 0x98563c8,
  tp_as_sequence = 0x985645c,
  tp_as_mapping = 0x9856450,
  tp_hash = 0x805f28f <PyObject_HashNotImplemented>,
  tp_call = 0,
  tp_str = 0x8078a2e <object_str>,
  tp_getattro = 0x805ff70 <PyObject_GenericGetAttr>,
  tp_setattro = 0x806029e <PyObject_GenericSetAttr>,
  tp_as_buffer = 0x9856484,
  tp_flags = 808448,
  tp_doc = 0x0,
  tp_traverse = 0x8073801 <subtype_traverse>,
  tp_clear = 0x8073a31 <subtype_clear>,
  tp_richcompare = 0x8080b08 <slot_tp_richcompare>,
  tp_weaklistoffset = ,
  tp_iter = 0,
  tp_iternext = 0x805fa55 <_PyObject_NextNotImplemented>,
  tp_methods = 0x0,
  tp_members = 0x9856494,
  tp_getset = 0x82a9b40,
  tp_base = 0x82aa020,
  tp_dict = ,
  tp_descr_get = 0,
  tp_descr_set = 0,
  tp_dictoffset = 16,
  tp_init = 0x8078462 <object_init>,
  tp_alloc = 0x807360b <PyType_GenericAlloc>,
  tp_new = 0x8078515 <object_new>,
  tp_free = 0x810b295 <PyObject_GC_Del>,
  tp_is_gc = 0,
  tp_bases = (<type at remote 0x82aa020>,),
  tp_mro = (<type at remote 0x98562fc>, <type at remote 0x82aa020>),
  tp_cache = 0x0,
  tp_subclasses = 0x0,
  tp_weaklist = <weakref at remote 0x98a0974>,
  tp_del = 0,
  tp_version_tag = 189
}

Note how the tp_getattro and tp_setattro point to generic methods PyObject_GenericGetAttr and PyObject_GenericSetAttr.

In the next article we will see how attribute lookup works.

(1) If in CPython methods are just a particular type of attribute, this is not the case for every dynamically-typed languages. In Ruby for example you only access attributes through methods. Something like “my_obj.my_attribute = 42” is syntactic sugar for calling the object setter method to modify its private attribute “my_attribute”.

(2) In most object-oriented language, “my_object.my_method(argument)” is the same as “MyObjectClass.my_method(my_object, argument)”. In the case of type(int), the confusing part is that “type” is both the class and the instance.

Immutable numbers

This has already been addressed in a previous post: numbers in Python are immutable. You do not change the content of a variable, you make it point to a new number object. There are several other languages that manage numbers as an object (Smalltalk, Objective C, Ruby). I don’t however know if they have immutable numbers (although Ruby seems to)

Immutable strings

The first immutable type that a programming language typically implements is strings. When a string gets created in Python, it never gets updated ever again – only deleted when it is not used anymore. You want to change a single character from that string? A new string will be created. What happens to the older string? It gets garbage-collected – provided it is not used somewhere else.

Immutable strings can however generate a lot of garbage objects (in a future post we will analyze how the CPython garbage collector works). Imagine you want to read a file and store the result in a variable.

file = open('myfile.txt', 'r')

text = ""
for line in file:
    text += line

Every loop generates 2 garbage objects: one for the line being read from the file, and one for the old version of “text”. If you are reading a file composed of 100 lines of 10 bytes each (so a 1000 bytes file), the whole operation generates 100 garbage objects for each line read (for a total of 1000 bytes) and 99 garbage objects for all the precious versions of “text” (for a total of 10 + 20 + 30 + … + 990 = 49500 bytes), for a grand total of 1000 + 49500 = 50500 bytes worth of garbage objects. Or over 50 times the size of the file (plus the overhead for all these objects) !

Because strings are immutable, this however mean that the same string can be shared by several variables. For example:

>>> def func():
...     print(id('Hello' + 'World'))
...     print(id('HelloWorld'))
...
>>> func()
42900400
42900400

The two strings generated have the same id, which means they point to the exact same object (id() actually returns the memory address of the object). Considering strings are immutable, it does not matter to the user whether two strings that contain the same text share the same object or not (except if you compare ids or use “string1 is string2”). Now, how does Python detects these are the same string? Let’s disassemble the function:

>>> import dis
>>> dis.dis(func)
  2           0 LOAD_GLOBAL              0 (print)
              3 LOAD_GLOBAL              1 (id)
              6 LOAD_CONST               4 ('HelloWorld')
              9 CALL_FUNCTION            1 (1 positional, 0 keyword pair)
             12 CALL_FUNCTION            1 (1 positional, 0 keyword pair)
             15 POP_TOP

  3          16 LOAD_GLOBAL              0 (print)
             19 LOAD_GLOBAL              1 (id)
             22 LOAD_CONST               3 ('HelloWorld')
             25 CALL_FUNCTION            1 (1 positional, 0 keyword pair)
             28 CALL_FUNCTION            1 (1 positional, 0 keyword pair)
             31 POP_TOP
             32 LOAD_CONST               0 (None)
             35 RETURN_VALUE
>>>
>>> func.__code__.co_consts
(None, 'Hello', 'World', 'HelloWorld', 'HelloWorld')

As you can see, the compiler detects the ‘Hello’ + ‘World’ operation and compiles it as ‘HelloWorld’. Interestingly, it is nonetheless using two different constants for the two strings (ids 4 and 3, and as shown at line 20). But Python has another optimization:

>>> string1 = 'HelloWorld'
>>> string2 = 'HelloWorld'
>>> id(string1)
35924656
>>> id(string2)
35924656

CPython keeps a dictionary of so-called interned strings which it can reuse when using variable names, attribute/method names or constants (here, the string ‘HelloWorld’ is compiled as a constant). This however does not work with strings that contain white spaces:

>>> string1 = 'Hello W'
>>> string2 = 'Hello W'
>>> id(string1)
35934312
>>> id(string2)
35934256

When it comes to constants, CPython is indeed only interning strings which are “valid name characters”. That is, contain only either alphanumeric characters and/or underscore characters⁽¹⁾. I assume the rationale is to only try to reuse strings used for symbols as they are the most likely to be reused. More complex strings, on the other hand, are more likely to be unique, to there is less to be gained by interning them.

It is however possible to force Python to use the interned dictionary for any type of string:

>>> from sys import intern
>>> a = intern('Hello W')
>>> b = intern('Hello W')
>>> id(a)
42651352
>>> id(b)
42651352

Immutable collections

Immutable collections are primarily used by functional programming languages (e.g. Scala, Haskell, F#). You do not insert an element in a collection, you create a new collection which contains the new element. In the case of a tree structure you do not even need to recreate a complete new tree and can reuse whole parts of the previous tree (the subtrees not affected by the change)

Python has some immutable collections with tuples and frozensets. Once you create a tuple, you cannot add elements to it. You cannot replace its elements. You can concatenate tuples, but this will only create a new tuple and won’t modify any of the source tuples. The only modification you can do is if you modify any mutable type inside the tuple, such as a list or a user class instance.

Because dictionary keys in Python are required to be immutable, you can use a tuple or a frozenset as a dictionary key.

Why immutability?

Using immutable structures has some implications. Consider the following code:

>>> class MyClass1(object):
...     allusers = ['John']
...     def add_user(self, user):
...             self.allusers.append(user)
...     def get_users(self):
...             return self.allusers
...
>>> obj = MyClass1()
>>> users = obj.get_users()
>>> users
['John']
>>> obj.add_user('Mary')
>>> users
['John', 'Mary']
>>> users.clear()
>>> obj.get_users()
[]

The get_users() method returns a dynamic list of users. Adding a new user afterwards gets reflected in “users”. However, because the result is mutable, the caller of get_users() can use functions such as append() or clear() that mutate the list. Let’s now look at a similar class which is instead using tuples:

>>> class MyClass2(object):
...     allusers = ('John',)
...     def add_user(self, user):
...             self.allusers += (user,)
...     def get_users(self):
...             return self.allusers
...
>>> obj = MyClass2()
>>> users = obj.get_users()
>>> users
('John',)
>>> obj.add_user('Mary')
>>> users
('John',)
>>> obj.get_users()
('John', 'Mary')

The caller of get_result() cannot update the result anymore as it is immutable. The “+=” operation does not mutable “users”. It creates a new tuple and makes “‘obj.allusers” point to that new structure. However, get_result() returns a snapshot of “obj.allusers” at the time it was called. That result may not even be up-to-date by the time the next instruction is executed. Adding new users indeed does not update “users”.

Immutability is mostly used when one wants to avoid that different various parts of a program step on each others toes – in particular in the case of high concurrency programs⁽²⁾. The caller of MyClass2.get_users() knows that, no matter what, the result will not change. It can for example store “len(users)” in a variable and use it later on, knowing it will always be consistent with “users”.

The flip side is that the result may not be up-to-date, but in some cases that is OK. For example when rendering a Web page. After all, a Web page can be seen as an immutable view of the server: it was a snapshot at the time it was being generated, and may not be up-to-date by the time it has finished downloading (unless you’re using Ajax but that’s another story)

Note that you do not necessarily need to use immutable structures to have an immutable effect. If you are getting the list through a SQL query, the result can be considered immutable in the sense any subsequent change to the database after the query is performed will not be reflected in the result. Sure, you can modify the results, but those changes will not be seen by anybody else.

But in the case of a resource in memory (like a list that stays in memory and which can be updated by several threads), it may be useful to use an immutable structure.

Last but not least, for those who are interested in the use of immutability in high-concurrency environments, Pat Helland (who worked at Microsoft, Amazon and Salesforce.com) gave a great talk called Immutability Changes Everything. He argues that, a few decades ago, computer resources were expensive but there was no problem grabbing a lock. Nowadays, hardware resources are pretty cheap (provided you don’t care about the quality). But try to grab a lock and all hell breaks loose.

(1) For those of you who really want to know how it is implemented, check out Objects/codeobject:

• The C function PyCode_New() is calling intern_strings() on the names, variable names and other symbols stored in the bytecode (lines 83 to 86)
  • intern_strings() (line 36) is in turn calling PyUnicode_InternInPlace() which is managing the interned dictionary (see Objects/unicodeobject.c line 14992)
• For constants however, they must first clear all_name_chars() (line 90) before PyUnicode_InternInPlace() is called (line 92)
  • all_name_chars() (line 11) checks that all the characters from the string belong to the list stored in NAME_CHARS (line 5)

(2) There is always some level of concurrency and mutability. At the very least the program needs to update the variable that references the immutable structure – and you want this operation to be atomic. But immutability nevertheless strongly reduces concurrency problems.

>>> def test():
...     for i in range(10):
...             print(i)
...

You can call dis.dis(test) to display the compiled bytecode, and dis.show_code(test) to understand the symbols referenced by that bytecode.

>>> import dis
>>> dis.dis(test)
  2           0 SETUP_LOOP              30 (to 33)
              3 LOAD_GLOBAL              0 (range)
              6 LOAD_CONST               1 (10)
              9 CALL_FUNCTION            1 (1 positional, 0 keyword pair)
             12 GET_ITER
        >>   13 FOR_ITER                16 (to 32)
             16 STORE_FAST               0 (i)

  3          19 LOAD_GLOBAL              1 (print)
             22 LOAD_FAST                0 (i)
             25 CALL_FUNCTION            1 (1 positional, 0 keyword pair)
             28 POP_TOP
             29 JUMP_ABSOLUTE           13
        >>   32 POP_BLOCK
        >>   33 LOAD_CONST               0 (None)
             36 RETURN_VALUE

>>> dis.show_code(test)
Name:              test
Filename:          <stdin>
Argument count:    0
Kw-only arguments: 0
Number of locals:  1
Stack size:        3
Flags:             OPTIMIZED, NEWLOCALS, NOFREE
Constants:
   0: None
   1: 10
Names:
   0: range
   1: print
Variable names:
   0: i

Understanding the bytecode

The output of dis.dis() is split in 4 columns:

• The first column represents the line number (line 2 is “for i in range(10):”, line 3 is “print(i)”)
• The second column is the bytecode offset in bytes (each bytecode instruction takes a certain number of bytes).
• The third column is the bytecode instruction (see the dis documentation for the instruction reference)
• The fourth column is the instruction argument, when any (in parenthesis is a more human-readable translation of this argument)

The CPython bytecode works in a very similar way than assembly languages such as x86 or ARM assembly. It is heavily relying on a stack where it will push arguments on top (using instructions such as LOAD_GLOBAL, LOAD_CONST, LOAD_FAST) and pop arguments off it (POP_TOP). Some instruction will also push a result on the stack.

Finally, like regular assembly languages, the CPython bytecode flow is heavily regulated by direct jumps (JUMP_ABSOLUTE) or relative jumps (e.g. 13 bytes after the next instruction)

However, the CPython bytecode contains high-level instructions such as GET_ITER or MAKE_FUNCTION that are not present in a traditional assembler.

For those who want to get more informations about do the bytecode instructions do, you can look at the C source code in Python/ceval.c.

Loops

The dis.dis() output above highlights the bytecode instructions that implement a loop:

Function calls

Python function calls are implemented by putting some arguments on the stack using bytecode instructions such as LOAD_GLOBAL (add a global variable), LOAD_CONST (add a constant), LOAD_FAST (add a local variable), etc. Let’s look at how the print(i) gets implemented:

  3          19 LOAD_GLOBAL              1 (print)
             22 LOAD_FAST                0 (i)
             25 CALL_FUNCTION            1 (1 positional, 0 keyword pair)
             28 POP_TOP

print

  i
print

None

Actual binary code

The dis library is relying on the __code__ attribute but makes it much easier to use. e.g. instead of the actual binary returned by __code__.co_code, dis.dis displays the bytecode functions in plain English.

>>> test.__code__
<code object test at 0x0000000002258270, file "<stdin>", line 1>
>>> test.__code__.co_code
b'x\x1e\x00t\x00\x00d\x01\x00\x83\x01\x00D]\x10\x00}\x00\x00t\x01\x00|\x00\x00\x83\x01\x00\x01q\r\x00Wd\x00\x00S'
>>> list(test.__code__.co_code)
[120, 30, 0, 116, 0, 0, 100, 1, 0, 131, 1, 0, 68, 93, 16, 0, 125, 0, 0, 116, 1, 0, 124, 0, 0, 131, 1, 0, 1, 113, 13, 0, 87, 100, 0, 0, 83]
>>> test.__code__.co_varnames
('i',)
>>> test.__code__.co_nlocals
1
>>> test.__code__.co_names
('range', 'print')

The line highlighted above corresponds to the actual compiled binary. The first number (120) is the opcode for SETUP_LOOP (look for 120 in Include/opcode.h), the next two numbers (30 and 0) represent the argument, or 30. Likewise, the “13” towards the end of the array corresponds to the argument passed to the “JUMP_ABSOLUTE 13” command. But using dis.dis() is definitely easier!

When dis.dis() is useful

We will see uses for dis.dis() in future posts, but for now one of its uses is when a piece of code does not behave as expected and you don’t know why. Consider the following code:

>>> a / b / c / d
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ZeroDivisionError: division by zero

We have a division by zero, but what variable is the cause for that error? If the code was inside some more complex code, it would require to step into the debugger. dis.dis() can however help shed some light on what happened.

>>> dis.dis()
  1           0 LOAD_NAME                0 (a)
              3 LOAD_NAME                1 (b)
    -->       6 BINARY_TRUE_DIVIDE
              7 LOAD_NAME                2 (c)
             10 BINARY_TRUE_DIVIDE
             11 LOAD_NAME                3 (d)
             14 BINARY_TRUE_DIVIDE
             15 PRINT_EXPR
             16 LOAD_CONST               0 (None)
             19 RETURN_VALUE

The line with the arrow (highlighted) indicates where the crash occurred: when trying to divide a with b (they have already been pushed on the stack). So we know that b is equal to zero.