Maxim Kulsha, profile picture
Uploaded byMaxim Kulsha
PDF, PPTX815 views

Беглый обзор "внутренностей" Python

Документ представляет собой обзор внутренностей Python и рассматривает важность понимания его работы, включая вопросы о потреблении памяти и скорости выполнения. Он обсуждает различные реализации Python, такие как CPython и их особенности, такие как управление памятью и объекты. Также документ объясняет принципы работы байткода и виртуальной машины, выполняющей Python-код.

Embed presentation

Download as PDF, PPTX
1 / 123
2 / 123
3 / 123
4 / 123
5 / 123
6 / 123
7 / 123
8 / 123
9 / 123
10 / 123
11 / 123
12 / 123
13 / 123
14 / 123
15 / 123
16 / 123
17 / 123
18 / 123
19 / 123
20 / 123
21 / 123
22 / 123
23 / 123
24 / 123
25 / 123
26 / 123
27 / 123
28 / 123
29 / 123
30 / 123
31 / 123
32 / 123
33 / 123
34 / 123
35 / 123
36 / 123
37 / 123
38 / 123
39 / 123
40 / 123
41 / 123
42 / 123
43 / 123
44 / 123
45 / 123
46 / 123
47 / 123
48 / 123
49 / 123
50 / 123
51 / 123
52 / 123
53 / 123
54 / 123
55 / 123
56 / 123
57 / 123
58 / 123
59 / 123
60 / 123
61 / 123
62 / 123
63 / 123
64 / 123
65 / 123
66 / 123
67 / 123
68 / 123
69 / 123
70 / 123
71 / 123
72 / 123
73 / 123
74 / 123
75 / 123
76 / 123
77 / 123
78 / 123
79 / 123
80 / 123
81 / 123
82 / 123
83 / 123
84 / 123
85 / 123
86 / 123
87 / 123
88 / 123
89 / 123
90 / 123
91 / 123
92 / 123
93 / 123
94 / 123
95 / 123
96 / 123
97 / 123
98 / 123
99 / 123
100 / 123
101 / 123
102 / 123
103 / 123
104 / 123
105 / 123
106 / 123
107 / 123
108 / 123
109 / 123
110 / 123
111 / 123
112 / 123
113 / 123
114 / 123
115 / 123
116 / 123
117 / 123
118 / 123
119 / 123
120 / 123
121 / 123
122 / 123
123 / 123
Беглый обзор “внутренностей” Python Никита Лесников
Почему это может быть полезно? Часто у программиста, использующего в работе Python, возникает один из следующих вопросов: какой из двух способов решения проблемы потребляет меньше памяти? Беглый обзор “внутренностей” Python 2
Почему это может быть полезно? Часто у программиста, использующего в работе Python, возникает один из следующих вопросов: какой из двух способов решения проблемы потребляет меньше памяти? какой из двух способов работает быстрее? Беглый обзор “внутренностей” Python 2
Почему это может быть полезно? Часто у программиста, использующего в работе Python, возникает один из следующих вопросов: какой из двух способов решения проблемы потребляет меньше памяти? какой из двух способов работает быстрее? как поведет себя определенная конструкция при изменении runtime среды? Беглый обзор “внутренностей” Python 2
Почему это может быть полезно? Решаются они обычно одним из следующих способов: можно спросить у коллег Беглый обзор “внутренностей” Python 3
Почему это может быть полезно? Решаются они обычно одним из следующих способов: можно спросить у коллег можно найти ответ на StackOverflow Беглый обзор “внутренностей” Python 3
Почему это может быть полезно? Решаются они обычно одним из следующих способов: можно спросить у коллег можно найти ответ на StackOverflow можно замерить самому Беглый обзор “внутренностей” Python 3
Почему это может быть полезно? Однако понимание того, как работает интерпретатор на самых нижних уровнях, позволяет обрести интуитивное понимание нюансов работы многих конструкций языка. Беглый обзор “внутренностей” Python 4
Почему это может быть полезно? Однако понимание того, как работает интерпретатор на самых нижних уровнях, позволяет обрести интуитивное понимание нюансов работы многих конструкций языка. Кроме того, в случае с Python абсолютное большинство программистов обладает достаточной квалификацией, чтобы без посредников найти ответ на свой вопрос в исходниках интерпретатора. Беглый обзор “внутренностей” Python 4
Почему это может быть полезно? Знакомство с “внутренностями” полезно также потому, что Python является open source проектом - кто знает, быть может именно вы решите одну из наболевших проблем? ;) Беглый обзор “внутренностей” Python 5
Почему это может быть полезно? Знакомство с “внутренностями” полезно также потому, что Python является open source проектом - кто знает, быть может именно вы решите одну из наболевших проблем? ;) Кратким изучением наиболее характерных особенностей интерпретатора мы сейчас и займемся. Беглый обзор “внутренностей” Python 5
CPython Основная реализация Python на сегодняшний день Беглый обзор “внутренностей” Python 6
CPython Основная реализация Python на сегодняшний день Написана на C (не С++), кроссплатформенна и довольно легко переносима на отличные от официально поддерживаемых платформы Беглый обзор “внутренностей” Python 6
CPython Основная реализация Python на сегодняшний день Написана на C (не С++), кроссплатформенна и довольно легко переносима на отличные от официально поддерживаемых платформы Код простой и понятный Беглый обзор “внутренностей” Python 6
CPython Основная реализация Python на сегодняшний день Написана на C (не С++), кроссплатформенна и довольно легко переносима на отличные от официально поддерживаемых платформы Код простой и понятный Нет, серьезно, простой и понятный, даже для людей, не интересующихся разработкой языков программирования ;) Беглый обзор “внутренностей” Python 6
CPython Есть еще PyPy, IronPython, Jython, Boo (хотя это не совсем Python) Беглый обзор “внутренностей” Python 7
CPython Есть еще PyPy, IronPython, Jython, Boo (хотя это не совсем Python) Они по своему интересны, но с CPython “внутри” у них мало общего Беглый обзор “внутренностей” Python 7
CPython Есть еще PyPy, IronPython, Jython, Boo (хотя это не совсем Python) Они по своему интересны, но с CPython “внутри” у них мало общего Поэтому хотя они и могут быть очень полезны на практике, рассматривать их мы не будем Беглый обзор “внутренностей” Python 7
Все - объект. Беглый обзор “внутренностей” Python 8
Все - объект В Python все является объектом Беглый обзор “внутренностей” Python 9
Все - объект В Python все является объектом Ну то есть вообще все - от чисел до стакфреймов Беглый обзор “внутренностей” Python 9
Все - объект В Python все является объектом Ну то есть вообще все - от чисел до стакфреймов На C-уровне это выражено типом PyObject * Беглый обзор “внутренностей” Python 9
Все - объект В Python все является объектом Ну то есть вообще все - от чисел до стакфреймов На C-уровне это выражено типом PyObject * Любой PyObject имеет стандартный заголовок: #define PyObject_HEAD Py_ssize_t ob_refcnt; struct _typeobject *ob_type; Беглый обзор “внутренностей” Python 9
Все - объект В Python все является объектом Ну то есть вообще все - от чисел до стакфреймов На C-уровне это выражено типом PyObject * Любой PyObject имеет стандартный заголовок: #define PyObject_HEAD Py_ssize_t ob_refcnt; struct _typeobject *ob_type; Поэтому в 64-битном Python число не может быть меньше 24 байт. Deal with it. Беглый обзор “внутренностей” Python 9
PyObject * #define PyObject_HEAD Py_ssize_t ob_refcnt; struct _typeobject *ob_type; ob_refcnt - reference counter ob_type - type object, определяющий поведение объекта и значение полей struct’а, идущих после заголовка (например, PyStringObject, PyIntObject) PyObject * - указатель. Поэтому все значения в Python передаются по ссылке. No exceptions. Беглый обзор “внутренностей” Python 10
Ссылки PyIntTypeObject PyIntObject ob_refcnt = 3 ob_type ob_ival = 42 a b c >>> a = b = c = 42 Все три имени ссылаются на один объект Этот факт можно установить при помощи is В общем случае == и is не эквивалентны Беглый обзор “внутренностей” Python 11
None None - особый объект Беглый обзор “внутренностей” Python 12
None None - особый объект Он один на каждый инстанс интерпретатора. Совсем один. Беглый обзор “внутренностей” Python 12
None None - особый объект Он один на каждый инстанс интерпретатора. Совсем один. Поэтому для него is и == всегда эквивалентны. Беглый обзор “внутренностей” Python 12
None None - особый объект Он один на каждый инстанс интерпретатора. Совсем один. Поэтому для него is и == всегда эквивалентны. Вот так вот делать не стоит: if x == None: это медленно, бессмысленно и вообще плохой тон. Беглый обзор “внутренностей” Python 12
int int - тип “малых” целых чисел Беглый обзор “внутренностей” Python 13
int int - тип “малых” целых чисел В Python целые - неизменяемый тип Беглый обзор “внутренностей” Python 13
int int - тип “малых” целых чисел В Python целые - неизменяемый тип Проверим как на них работает is: >>> int("100") is int("100") True >>> int("1000") is int("1000") False Беглый обзор “внутренностей” Python 13
int int - тип “малых” целых чисел В Python целые - неизменяемый тип Проверим как на них работает is: >>> int("100") is int("100") True >>> int("1000") is int("1000") False Как это объяснить? Оказывается, интерпретатор “кеширует” объекты int со значениями от -5 до 256, для других значений создаются самостоятельные объекты. Беглый обзор “внутренностей” Python 13
int int - тип “малых” целых чисел В Python целые - неизменяемый тип Проверим как на них работает is: >>> int("100") is int("100") True >>> int("1000") is int("1000") False Как это объяснить? Оказывается, интерпретатор “кеширует” объекты int со значениями от -5 до 256, для других значений создаются самостоятельные объекты. Поэтому список intов размером до байта будет иметь overhead в 8 байт на элемент (указатель), а больших intов - до 32 байт на элемент (указатель + объект). Беглый обзор “внутренностей” Python 13
int Но загадки на этом не заканчиваются: >>> (1000 is 1000, 1000+0 is 1000+0) (True, False) Беглый обзор “внутренностей” Python 14
int Но загадки на этом не заканчиваются: >>> (1000 is 1000, 1000+0 is 1000+0) (True, False) Почему так - немного дальше. Беглый обзор “внутренностей” Python 14
string Строки, как и целые, в Python неизменяемы Беглый обзор “внутренностей” Python 15
string Строки, как и целые, в Python неизменяемы Однако sharing объектов их затрагивает куда сильнее Беглый обзор “внутренностей” Python 15
string Строки, как и целые, в Python неизменяемы Однако sharing объектов их затрагивает куда сильнее Интерпретатор поддерживает dict так называемых interned строк, для каждой из которых гарантированно существует ровно один объект Беглый обзор “внутренностей” Python 15
string Строки, как и целые, в Python неизменяемы Однако sharing объектов их затрагивает куда сильнее Интерпретатор поддерживает dict так называемых interned строк, для каждой из которых гарантированно существует ровно один объект Все идентификаторы (имена переменных, модулей, методов), автоматически туда помещаются Беглый обзор “внутренностей” Python 15
string Строки, как и целые, в Python неизменяемы Однако sharing объектов их затрагивает куда сильнее Интерпретатор поддерживает dict так называемых interned строк, для каждой из которых гарантированно существует ровно один объект Все идентификаторы (имена переменных, модулей, методов), автоматически туда помещаются Оператор == для interned строк выраждается в is (сравнение указателей) Беглый обзор “внутренностей” Python 15
string Строки, как и целые, в Python неизменяемы Однако sharing объектов их затрагивает куда сильнее Интерпретатор поддерживает dict так называемых interned строк, для каждой из которых гарантированно существует ровно один объект Все идентификаторы (имена переменных, модулей, методов), автоматически туда помещаются Оператор == для interned строк выраждается в is (сравнение указателей) Помимо этого, по аналогии с int со значениями [−5, 256] разделяются объекты пустой и всех возможных однобуквенных строк Беглый обзор “внутренностей” Python 15
Краткий вывод Не используйте is для чего-то кроме None Беглый обзор “внутренностей” Python 16
Краткий вывод Не используйте is для чего-то кроме None Unless you know what you’re doing Беглый обзор “внутренностей” Python 16
Байткод Беглый обзор “внутренностей” Python 17
Виртуальная машина “Железный” процессор не может напрямую выполнять код на C Беглый обзор “внутренностей” Python 18
Виртуальная машина “Железный” процессор не может напрямую выполнять код на C Его сначала нужно “разжевать” до очень простых операций, работающих с адресами и регистрами Беглый обзор “внутренностей” Python 18
Виртуальная машина “Железный” процессор не может напрямую выполнять код на C Его сначала нужно “разжевать” до очень простых операций, работающих с адресами и регистрами Код на Python также не годится для непосредственного исполнения Беглый обзор “внутренностей” Python 18
Виртуальная машина “Железный” процессор не может напрямую выполнять код на C Его сначала нужно “разжевать” до очень простых операций, работающих с адресами и регистрами Код на Python также не годится для непосредственного исполнения Поэтому скрипт при загрузке транслируется в байткод виртуальной машины Беглый обзор “внутренностей” Python 18
Виртуальная машина “Железный” процессор не может напрямую выполнять код на C Его сначала нужно “разжевать” до очень простых операций, работающих с адресами и регистрами Код на Python также не годится для непосредственного исполнения Поэтому скрипт при загрузке транслируется в байткод виртуальной машины Виртуальная машина (VM) - это подпрограмма интерпретатора, испоняющая байткод. Беглый обзор “внутренностей” Python 18
Виртуальная машина “Железный” процессор не может напрямую выполнять код на C Его сначала нужно “разжевать” до очень простых операций, работающих с адресами и регистрами Код на Python также не годится для непосредственного исполнения Поэтому скрипт при загрузке транслируется в байткод виртуальной машины Виртуальная машина (VM) - это подпрограмма интерпретатора, испоняющая байткод. Но кроме отсутствия “железного” воплощения, концептуальных различий с процессором нет. Беглый обзор “внутренностей” Python 18
Байткод Команды CPython VM кодируются одним байтом Беглый обзор “внутренностей” Python 19
Байткод Команды CPython VM кодируются одним байтом Каждая из них может иметь опциональный 16-битный аргумент Беглый обзор “внутренностей” Python 19
Байткод Команды CPython VM кодируются одним байтом Каждая из них может иметь опциональный 16-битный аргумент Концептуально VM является стековой машиной (уместны аналогии с обратной польской записью и языком Forth) - значения кладутся на value stack (не путать с call stack), операции их снимают с вершины и кладут результат обратно. Беглый обзор “внутренностей” Python 19
Байткод Команды CPython VM кодируются одним байтом Каждая из них может иметь опциональный 16-битный аргумент Концептуально VM является стековой машиной (уместны аналогии с обратной польской записью и языком Forth) - значения кладутся на value stack (не путать с call stack), операции их снимают с вершины и кладут результат обратно. При помощи модуля dis можно посмотреть на байткод “живых” функций Беглый обзор “внутренностей” Python 19
def f(): a = 1 b = 2 c = 3 return a + b * c 2 0 LOAD_CONST 1 (1) 3 STORE_FAST 0 (a) 3 6 LOAD_CONST 2 (2) 9 STORE_FAST 1 (b) 4 12 LOAD_CONST 3 (3) 15 STORE_FAST 2 (c) 5 18 LOAD_FAST 0 (a) 21 LOAD_FAST 1 (b) 24 LOAD_FAST 2 (c) 27 BINARY_MULTIPLY 28 BINARY_ADD 29 RETURN_VALUE Беглый обзор “внутренностей” Python 20
Константы def f(): return (1,"abc", 3.0) Беглый обзор “внутренностей” Python 21
Константы def f(): return (1,"abc", 3.0) >>> dis.dis(f) 2 0 LOAD_CONST 4 ((1, ’abc’, 3.0)) 3 RETURN_VALUE Беглый обзор “внутренностей” Python 21
Константы def f(): return (1,"abc", 3.0) >>> dis.dis(f) 2 0 LOAD_CONST 4 ((1, ’abc’, 3.0)) 3 RETURN_VALUE >>> f.__code__.co_consts (None, 1, ’abc’, 3.0, (1, ’abc’, 3.0)) Беглый обзор “внутренностей” Python 21
Code object Как мы видим, байткод это не просто строка байт, так как 16-битных целых недостаточно, чтобы кодировать любые Python-объекты Беглый обзор “внутренностей” Python 22
Code object Как мы видим, байткод это не просто строка байт, так как 16-битных целых недостаточно, чтобы кодировать любые Python-объекты Однако их достаточно, чтобы кодировать смещения. Например, в список констант co_consts Беглый обзор “внутренностей” Python 22
Code object Как мы видим, байткод это не просто строка байт, так как 16-битных целых недостаточно, чтобы кодировать любые Python-объекты Однако их достаточно, чтобы кодировать смещения. Например, в список констант co_consts Наряду с другой метаинформацией (количество локальных переменных, количество параметров, глубина стека) байткод формирует code object Беглый обзор “внутренностей” Python 22
Code object Как мы видим, байткод это не просто строка байт, так как 16-битных целых недостаточно, чтобы кодировать любые Python-объекты Однако их достаточно, чтобы кодировать смещения. Например, в список констант co_consts Наряду с другой метаинформацией (количество локальных переменных, количество параметров, глубина стека) байткод формирует code object Именно code object являет собой единицу существования компилированного кода в Python Беглый обзор “внутренностей” Python 22
Code object Как мы видим, байткод это не просто строка байт, так как 16-битных целых недостаточно, чтобы кодировать любые Python-объекты Однако их достаточно, чтобы кодировать смещения. Например, в список констант co_consts Наряду с другой метаинформацией (количество локальных переменных, количество параметров, глубина стека) байткод формирует code object Именно code object являет собой единицу существования компилированного кода в Python Они же сериализуются в .pyc файлы Беглый обзор “внутренностей” Python 22
Code object code object являются неизменяемыми Беглый обзор “внутренностей” Python 23
Code object code object являются неизменяемыми В “нормальном” коде они строятся единожды - при загрузке модуля Беглый обзор “внутренностей” Python 23
Code object code object являются неизменяемыми В “нормальном” коде они строятся единожды - при загрузке модуля Это такой же объект как и все: def f(): def g(): pass return g 2 0 LOAD_CONST 1 (<code object f ...>) 3 MAKE_FUNCTION 0 6 STORE_FAST 0 (f) 3 9 LOAD_GLOBAL 0 (g) 12 RETURN_VALUE Беглый обзор “внутренностей” Python 23
Компиляция Процесс преобразования исходного кода модуля в набор code object называется компиляцией Беглый обзор “внутренностей” Python 24
Компиляция Процесс преобразования исходного кода модуля в набор code object называется компиляцией Однако компилятор у Python очень рудиментарный - фактически 1-в-1 отображение конструкций в байткод Беглый обзор “внутренностей” Python 24
Компиляция Процесс преобразования исходного кода модуля в набор code object называется компиляцией Однако компилятор у Python очень рудиментарный - фактически 1-в-1 отображение конструкций в байткод Оптимизаций уровня байткода почти нет Беглый обзор “внутренностей” Python 24
Компиляция Процесс преобразования исходного кода модуля в набор code object называется компиляцией Однако компилятор у Python очень рудиментарный - фактически 1-в-1 отображение конструкций в байткод Оптимизаций уровня байткода почти нет uncompyle, open source декомпилятор Python, способен восстановить исходный код по .pyc файлу почти всегда, потеряв при этом разве что комментарии Беглый обзор “внутренностей” Python 24
Компиляция Процесс преобразования исходного кода модуля в набор code object называется компиляцией Однако компилятор у Python очень рудиментарный - фактически 1-в-1 отображение конструкций в байткод Оптимизаций уровня байткода почти нет uncompyle, open source декомпилятор Python, способен восстановить исходный код по .pyc файлу почти всегда, потеряв при этом разве что комментарии Так как компилятор неоптимизирующий, ему почти всегда можно помочь (если надо) Беглый обзор “внутренностей” Python 24
Компиляция def f(): l = [] for i in xrange(10000): l.append(i) >>> timeit.timeit("""....""") 0.09371685981750488 >>> dis.dis(f) (... оставлено только тело цикла ...) 4 25 LOAD_FAST 0 (l) 28 LOAD_ATTR 1 (append) 31 LOAD_FAST 1 (i) 34 CALL_FUNCTION 1 Беглый обзор “внутренностей” Python 25
Loop hoisting LOAD_ATTR по идее выполняется небыстро - это поиск строки с именем метода в дикте (хеш-таблице). Строка interned, но все равно это долго. Беглый обзор “внутренностей” Python 26
Loop hoisting LOAD_ATTR по идее выполняется небыстро - это поиск строки с именем метода в дикте (хеш-таблице). Строка interned, но все равно это долго. Логично не выполнять эту операцию в теле цикла, а сделать ее единожды до начала выполнения. Беглый обзор “внутренностей” Python 26
Loop hoisting LOAD_ATTR по идее выполняется небыстро - это поиск строки с именем метода в дикте (хеш-таблице). Строка interned, но все равно это долго. Логично не выполнять эту операцию в теле цикла, а сделать ее единожды до начала выполнения. Эта оптимизация известна как loop hoisting, но рудиментарный компилятор Python ее не делает. Беглый обзор “внутренностей” Python 26
Loop hoisting LOAD_ATTR по идее выполняется небыстро - это поиск строки с именем метода в дикте (хеш-таблице). Строка interned, но все равно это долго. Логично не выполнять эту операцию в теле цикла, а сделать ее единожды до начала выполнения. Эта оптимизация известна как loop hoisting, но рудиментарный компилятор Python ее не делает. Поможем ему! Беглый обзор “внутренностей” Python 26
Loop hoisting def f(): l = [] la = l.append for i in xrange(10000): la(i) >>> timeit.timeit("""....""") 0.08451047520987543 >>> dis.dis(f) (... оставлено только тело цикла ...) 5 34 LOAD_FAST 1 (la) 37 LOAD_FAST 2 (i) 40 CALL_FUNCTION 1 До оптимизации было 0.09371685981750488. Разница - 10%. Беглый обзор “внутренностей” Python 27
LIST_APPEND Добавление к списку - частая операция, и потому в CPython VM есть особый опкод LIST_APPEND Беглый обзор “внутренностей” Python 28
LIST_APPEND Добавление к списку - частая операция, и потому в CPython VM есть особый опкод LIST_APPEND Как показывает изучение исходников компилятора, используется этот опкод только для компиляции list comprehensions: def f(): return [x for x in xrange(10000)] >>> timeit.timeit("""....""") 0.08152854398842842 >>> dis.dis(f) (... оставлено только тело цикла ...) 16 STORE_FAST 0 (x) 19 LOAD_FAST 0 (x) 22 LIST_APPEND 2 Беглый обзор “внутренностей” Python 28
Неймспейсы Беглый обзор “внутренностей” Python 29
Дикты и строки Многие знакомые с семантикой Python люди шутят, что Гвидо ван Россум написал dict (открытую хеш-таблицу) и string (неизменяемые строки), после чего решил больше ничего не писать Беглый обзор “внутренностей” Python 30
Дикты и строки Многие знакомые с семантикой Python люди шутят, что Гвидо ван Россум написал dict (открытую хеш-таблицу) и string (неизменяемые строки), после чего решил больше ничего не писать Действительно, объекты, модули и неймспейсы - все это обычные дикты cо строковыми ключами Беглый обзор “внутренностей” Python 30
Дикты и строки Многие знакомые с семантикой Python люди шутят, что Гвидо ван Россум написал dict (открытую хеш-таблицу) и string (неизменяемые строки), после чего решил больше ничего не писать Действительно, объекты, модули и неймспейсы - все это обычные дикты cо строковыми ключами Глобальное пространство имен модуля, следовательно, тоже дикт, а обращение к переменной - это lookup в дикте. Беглый обзор “внутренностей” Python 30
Дикты и строки Многие знакомые с семантикой Python люди шутят, что Гвидо ван Россум написал dict (открытую хеш-таблицу) и string (неизменяемые строки), после чего решил больше ничего не писать Действительно, объекты, модули и неймспейсы - все это обычные дикты cо строковыми ключами Глобальное пространство имен модуля, следовательно, тоже дикт, а обращение к переменной - это lookup в дикте. Всегда ли это так? Беглый обзор “внутренностей” Python 30
Дикты и строки def f(): a = 3 return a + b 2 0 LOAD_CONST 1 (1) 3 STORE_FAST 0 (a) 3 6 LOAD_FAST 0 (a) 9 LOAD_GLOBAL 0 (b) 12 BINARY_ADD 13 RETURN_VALUE Беглый обзор “внутренностей” Python 31
LOAD_FAST и LOAD_GLOBAL 3 6 LOAD_FAST 0 (a) 9 LOAD_GLOBAL 0 (b) Для имен a и b компилятор использовал разные опкоды. Почему? Беглый обзор “внутренностей” Python 32
LOAD_FAST и LOAD_GLOBAL 3 6 LOAD_FAST 0 (a) 9 LOAD_GLOBAL 0 (b) Для имен a и b компилятор использовал разные опкоды. Почему? Оказывается, на этапе компиляции в code object собираются все имена локальных переменных (то есть присваиваемые в этом блоке кода и не помеченные явно при помощи global), и заносятся в список co_locals. Беглый обзор “внутренностей” Python 32
LOAD_FAST и LOAD_GLOBAL 3 6 LOAD_FAST 0 (a) 9 LOAD_GLOBAL 0 (b) Для имен a и b компилятор использовал разные опкоды. Почему? Оказывается, на этапе компиляции в code object собираются все имена локальных переменных (то есть присваиваемые в этом блоке кода и не помеченные явно при помощи global), и заносятся в список co_locals. Впоследствии для каждого фрейма стека создается массив локальных переменных, и обращение к ним происходит по их индексу в co_locals. Этот индекс неизменен и “зашит” в байткод. Беглый обзор “внутренностей” Python 32
LOAD_FAST и LOAD_GLOBAL LOAD_FAST, как нетрудно догадаться, просто берет значение по индексу из массива Беглый обзор “внутренностей” Python 33
LOAD_FAST и LOAD_GLOBAL LOAD_FAST, как нетрудно догадаться, просто берет значение по индексу из массива LOAD_GLOBAL же вынужден брать строку с именем из co_consts, после чего искать по этому ключу в дикте неймспейса Беглый обзор “внутренностей” Python 33
LOAD_FAST и LOAD_GLOBAL LOAD_FAST, как нетрудно догадаться, просто берет значение по индексу из массива LOAD_GLOBAL же вынужден брать строку с именем из co_consts, после чего искать по этому ключу в дикте неймспейса Обе операции выполняются с ожидаемой стоимостью O(1), но у массива константа явно лучше Беглый обзор “внутренностей” Python 33
LOAD_FAST и LOAD_GLOBAL LOAD_FAST, как нетрудно догадаться, просто берет значение по индексу из массива LOAD_GLOBAL же вынужден брать строку с именем из co_consts, после чего искать по этому ключу в дикте неймспейса Обе операции выполняются с ожидаемой стоимостью O(1), но у массива константа явно лучше Поэтому закешировать что-то в локальную переменную не самая плохая идея в плане производительности Беглый обзор “внутренностей” Python 33
Lexical scoping Глобальный и локальный неймспейсы достаточно очевидны сами по себе Беглый обзор “внутренностей” Python 34
Lexical scoping Глобальный и локальный неймспейсы достаточно очевидны сами по себе Однако Python позволяет делать вот так: def f(): a = 1 def g(): return a return g >>> t = f() >>> t() 1 Беглый обзор “внутренностей” Python 34
Lexical scoping Глобальный и локальный неймспейсы достаточно очевидны сами по себе Однако Python позволяет делать вот так: def f(): a = 1 def g(): return a return g >>> t = f() >>> t() 1 Как возвращенной функции удается вернуть значение из разрушенного фрейма? Беглый обзор “внутренностей” Python 34
Lexical scoping Оказывается, такая ситуация детектируется при компиляции и решается при помощи создания cell object (в функциональных языках подобные объекты называют замыканиями или closures): 2 0 LOAD_CONST 1 (1) 3 STORE_DEREF 0 (a) 3 6 LOAD_CLOSURE 0 (a) 9 BUILD_TUPLE 1 12 LOAD_CONST 2 (<code object ...>) 15 MAKE_CLOSURE 0 18 STORE_FAST 0 (g) 4 21 LOAD_FAST 0 (g) 24 RETURN_VALUE Беглый обзор “внутренностей” Python 35
Lexical scoping Оказывается, такая ситуация детектируется при компиляции и решается при помощи создания cell object (в функциональных языках подобные объекты называют замыканиями или closures): 2 0 LOAD_CONST 1 (1) 3 STORE_DEREF 0 (a) 3 6 LOAD_CLOSURE 0 (a) 9 BUILD_TUPLE 1 12 LOAD_CONST 2 (<code object ...>) 15 MAKE_CLOSURE 0 18 STORE_FAST 0 (g) 4 21 LOAD_FAST 0 (g) 24 RETURN_VALUE cell object - это код функции вместе со значениями “внешних” (свободных, free) переменных Беглый обзор “внутренностей” Python 35
Lexical scoping cell object по времени жизни не привязан к фрейму, в котором он создан, и собирается сборщиком мусора только тогда, когда станет недостижим. Беглый обзор “внутренностей” Python 36
Lexical scoping cell object по времени жизни не привязан к фрейму, в котором он создан, и собирается сборщиком мусора только тогда, когда станет недостижим. Это “взрослая” реализация лексической области видимости Беглый обзор “внутренностей” Python 36
Lexical scoping cell object по времени жизни не привязан к фрейму, в котором он создан, и собирается сборщиком мусора только тогда, когда станет недостижим. Это “взрослая” реализация лексической области видимости Однако, к сожалению, она неполна: def f(): a = 1 if True: a = 2; print a print a этот код выведет 2 2. Аналогичный код на C++, или, скажем, Lua, выдаст 2 1 Беглый обзор “внутренностей” Python 36
Lexical scoping cell object по времени жизни не привязан к фрейму, в котором он создан, и собирается сборщиком мусора только тогда, когда станет недостижим. Это “взрослая” реализация лексической области видимости Однако, к сожалению, она неполна: def f(): a = 1 if True: a = 2; print a print a этот код выведет 2 2. Аналогичный код на C++, или, скажем, Lua, выдаст 2 1 Это источник трудноуловимых багов Беглый обзор “внутренностей” Python 36
Выстрелить в ногу! Что выведет это код? l = [lambda: x for x in "abcdefg"] for r in l: print r(), Беглый обзор “внутренностей” Python 37
Выстрелить в ногу! Что выведет это код? l = [lambda: x for x in "abcdefg"] for r in l: print r(), Наверное a b c d e f g? Беглый обзор “внутренностей” Python 37
Выстрелить в ногу! Что выведет это код? l = [lambda: x for x in "abcdefg"] for r in l: print r(), Наверное a b c d e f g? Реальность жестока. Беглый обзор “внутренностей” Python 37
Выстрелить в ногу! Что выведет это код? l = [lambda: x for x in "abcdefg"] for r in l: print r(), Наверное a b c d e f g? Реальность жестока. Правильный ответ - g g g g g g g. Беглый обзор “внутренностей” Python 37
Lexical scoping К сожалению, различие поведения областей видимости на макро- и микроуровнях настолько глубоко зашито в архитектуре языка, что поправить его практически нереально Беглый обзор “внутренностей” Python 38
Lexical scoping К сожалению, различие поведения областей видимости на макро- и микроуровнях настолько глубоко зашито в архитектуре языка, что поправить его практически нереально Даже если это сделать - это с большой вероятностью приведет к “ломанию” имеющегося кода Беглый обзор “внутренностей” Python 38
Lexical scoping К сожалению, различие поведения областей видимости на макро- и микроуровнях настолько глубоко зашито в архитектуре языка, что поправить его практически нереально Даже если это сделать - это с большой вероятностью приведет к “ломанию” имеющегося кода Поэтому про данную особенность надо просто помнить, и не сильно увлекаться функциональным программированием на Python ;) Беглый обзор “внутренностей” Python 38
Заключение Беглый обзор “внутренностей” Python 39
Заключение К сожалению, регламент данного доклада не дает слишком разогнаться. За бортом остаются многие интересные темы: Беглый обзор “внутренностей” Python 40
Заключение К сожалению, регламент данного доклада не дает слишком разогнаться. За бортом остаются многие интересные темы: Global Interpreter Lock (GIL), или почему программы на Python на нескольких ядрах работают медленнее, чем на одном Беглый обзор “внутренностей” Python 40
Заключение К сожалению, регламент данного доклада не дает слишком разогнаться. За бортом остаются многие интересные темы: Global Interpreter Lock (GIL), или почему программы на Python на нескольких ядрах работают медленнее, чем на одном frame object и их список, или как greenlet умудряется эмулировать кооперативную многозадачность “срезанием” стека Беглый обзор “внутренностей” Python 40
Заключение К сожалению, регламент данного доклада не дает слишком разогнаться. За бортом остаются многие интересные темы: Global Interpreter Lock (GIL), или почему программы на Python на нескольких ядрах работают медленнее, чем на одном frame object и их список, или как greenlet умудряется эмулировать кооперативную многозадачность “срезанием” стека ООП в Python, или почему у object нельзя выставить атрибут, а у унаследованного от него пустого класса - можно Беглый обзор “внутренностей” Python 40
Заключение К сожалению, регламент данного доклада не дает слишком разогнаться. За бортом остаются многие интересные темы: Global Interpreter Lock (GIL), или почему программы на Python на нескольких ядрах работают медленнее, чем на одном frame object и их список, или как greenlet умудряется эмулировать кооперативную многозадачность “срезанием” стека ООП в Python, или почему у object нельзя выставить атрибут, а у унаследованного от него пустого класса - можно Генераторы, или как “шаманство” с фреймами позволяет создавать видимость их (генераторов) наличия, но с серьезными ограничениями Беглый обзор “внутренностей” Python 40
Заключение Однако большой проблемы нет - это не сакральное знание Беглый обзор “внутренностей” Python 41
Заключение Однако большой проблемы нет - это не сакральное знание Все, что я вам сегодня рассказал, я не прочитал в интернете и на StackOverflow - я прочитал это в исходных кодах интерпретатора Беглый обзор “внутренностей” Python 41
Заключение Однако большой проблемы нет - это не сакральное знание Все, что я вам сегодня рассказал, я не прочитал в интернете и на StackOverflow - я прочитал это в исходных кодах интерпретатора Они действительно неплохо структурированы и их довольно просто читать, даже людям без соответствующего бэкграунда Беглый обзор “внутренностей” Python 41
Заключение Однако большой проблемы нет - это не сакральное знание Все, что я вам сегодня рассказал, я не прочитал в интернете и на StackOverflow - я прочитал это в исходных кодах интерпретатора Они действительно неплохо структурированы и их довольно просто читать, даже людям без соответствующего бэкграунда Мне это помогло глубже понять как работает тот код, который я пишу, что порой оказывалось очень полезным при профайлинге критичных мест Беглый обзор “внутренностей” Python 41
Заключение Однако большой проблемы нет - это не сакральное знание Все, что я вам сегодня рассказал, я не прочитал в интернете и на StackOverflow - я прочитал это в исходных кодах интерпретатора Они действительно неплохо структурированы и их довольно просто читать, даже людям без соответствующего бэкграунда Мне это помогло глубже понять как работает тот код, который я пишу, что порой оказывалось очень полезным при профайлинге критичных мест Это как раз тот случай, когда вместо того, чтобы лезть на StackOverflow, полезнее и интереснее разобраться самому. Так что дерзайте! Беглый обзор “внутренностей” Python 41
Благодарю за внимание!
Вопросы?

More Related Content

PDF
Введение в динамический анализ приложений на примере Intel Pin
bySemen Martynov
 
PPTX
Python AST / Николай Карелин / VPI Development Center [Python Meetup 27.03.15]
byPython Meetup
 
PPTX
409bb948 9463-4d6b-b885-63955ea67f1e-210512195958
byvavaxd
 
PPTX
Natural Language Processing (NLP) with .NET for #dotnetby meetup-29
bySergey Tihon
 
PDF
Back to the future: Функциональное программирование вчера и сегодня
byAlexander Granin
 
PPTX
Tomita
byNLPseminar
 
PDF
Теория языков программирования некоторые слайды к лекциям
bySergey Staroletov
 
PPTX
Tomita одесса
byNatalia Ostapuk
 
Введение в динамический анализ приложений на примере Intel Pin
bySemen Martynov
 
Python AST / Николай Карелин / VPI Development Center [Python Meetup 27.03.15]
byPython Meetup
 
409bb948 9463-4d6b-b885-63955ea67f1e-210512195958
byvavaxd
 
Natural Language Processing (NLP) with .NET for #dotnetby meetup-29
bySergey Tihon
 
Back to the future: Функциональное программирование вчера и сегодня
byAlexander Granin
 
Tomita
byNLPseminar
 
Теория языков программирования некоторые слайды к лекциям
bySergey Staroletov
 
Tomita одесса
byNatalia Ostapuk
 

What's hot

PDF
C++ Базовый. Занятие 01.
byIgor Shkulipa
 
PPTX
Эффективный C++
byAndrey Karpov
 
PPTX
NLTK и Python для работы с текстами
byNLProc.by
 
PPT
java 8
byUnguryan Vitaliy
 
PDF
ООП в Python
bySergey Ivanov
 
PDF
модель акторов и C++ что, зачем и как ?
bycorehard_by
 
PPTX
закон иерархических компенсаций седова и C++ core guidelines
byCOMAQA.BY
 
ODP
Intelligent или сделай мне красиво
byArtem Malyshev
 
PDF
Релиз PHP7 - что нас ждет в октябре 2015
byAndrey Tokarchuk
 
PDF
Open Corpora
byLidia Pivovarova
 
PDF
"Как Яндекс распознаёт музыку с микрофона". Евгений Крофто, Яндекс
byYandex
 
PPT
Java. Логические операторы, операторы ветвления.
byUnguryan Vitaliy
 
C++ Базовый. Занятие 01.
byIgor Shkulipa
 
Эффективный C++
byAndrey Karpov
 
NLTK и Python для работы с текстами
byNLProc.by
 
java 8
byUnguryan Vitaliy
 
ООП в Python
bySergey Ivanov
 
модель акторов и C++ что, зачем и как ?
bycorehard_by
 
закон иерархических компенсаций седова и C++ core guidelines
byCOMAQA.BY
 
Intelligent или сделай мне красиво
byArtem Malyshev
 
Релиз PHP7 - что нас ждет в октябре 2015
byAndrey Tokarchuk
 
Open Corpora
byLidia Pivovarova
 
"Как Яндекс распознаёт музыку с микрофона". Евгений Крофто, Яндекс
byYandex
 
Java. Логические операторы, операторы ветвления.
byUnguryan Vitaliy
 

Viewers also liked

PDF
Rujikon
byIndiaMART InterMESH Limited
 
PPTX
Aula de convivencia presentacion
byYolita Mendoza Ayala
 
PDF
Mobile Search Moments Study : Creating moments-that-matter research-studies
bymanish kumar
 
PDF
Ceremonia blanca. nov 8
byJuliana Robledo Ramírez
 
PPTX
bidrink elevator pitch
byapazosm
 
DOCX
Library voxengo effect improved work
byLuke Finlay
 
Rujikon
byIndiaMART InterMESH Limited
 
Aula de convivencia presentacion
byYolita Mendoza Ayala
 
Mobile Search Moments Study : Creating moments-that-matter research-studies
bymanish kumar
 
Ceremonia blanca. nov 8
byJuliana Robledo Ramírez
 
bidrink elevator pitch
byapazosm
 
Library voxengo effect improved work
byLuke Finlay
 

Similar to Беглый обзор "внутренностей" Python

PDF
"Внутренности" CPython, часть II
byPython Meetup
 
PPTX
Занятие 1.pptxsadasdasdasdasasdasdasdasdas
bymdxsambf
 
PDF
Введение в Python и Django
byTaras Lyapun
 
PDF
Лекция #5. Введение в язык программирования Python 3
byЯковенко Кирилл
 
PPTX
слайд питон БОН.pptx
byHSharipov
 
PDF
«Память и Python. Что надо знать для счастья?» Алексей Кузьмин, ЦНС
byit-people
 
PPTX
Mixing c++ and python
bycorehard_by
 
PDF
Python и высокая нагрузка
byAlexander Shigin
 
PPTX
Python-технология которую легко продавать!
byAleksey Nakorenko
 
PDF
Python и Cython
byAlexander Shigin
 
PDF
Лекция 1. Начало.
byRoman Brovko
 
PPTX
Программирование как способ выражения мыслей.
byLevon Avakyan
 
ODP
About Python
byYury Yurevich
 
PDF
Мир Python функционалим с помощью библиотек
byPyNSK
 
PDF
Kranonit s16 (python). sergey burma
byKrivoy Rog IT Community
 
PDF
ekbpy'2012 - Михаил Коробов - Python 3
byit-people
 
PDF
Python и его тормоза
byAlexander Shigin
 
PPT
Join the python_side
byPaul Dmitryev
 
ODP
Charming python sc2-8
byVladislav Ananev
 
PDF
8 встреча — Язык программирования Python (В. Ананьев)
bySmolensk Computer Science Club
 
"Внутренности" CPython, часть II
byPython Meetup
 
Занятие 1.pptxsadasdasdasdasasdasdasdasdas
bymdxsambf
 
Введение в Python и Django
byTaras Lyapun
 
Лекция #5. Введение в язык программирования Python 3
byЯковенко Кирилл
 
слайд питон БОН.pptx
byHSharipov
 
«Память и Python. Что надо знать для счастья?» Алексей Кузьмин, ЦНС
byit-people
 
Mixing c++ and python
bycorehard_by
 
Python и высокая нагрузка
byAlexander Shigin
 
Python-технология которую легко продавать!
byAleksey Nakorenko
 
Python и Cython
byAlexander Shigin
 
Лекция 1. Начало.
byRoman Brovko
 
Программирование как способ выражения мыслей.
byLevon Avakyan
 
About Python
byYury Yurevich
 
Мир Python функционалим с помощью библиотек
byPyNSK
 
Kranonit s16 (python). sergey burma
byKrivoy Rog IT Community
 
ekbpy'2012 - Михаил Коробов - Python 3
byit-people
 
Python и его тормоза
byAlexander Shigin
 
Join the python_side
byPaul Dmitryev
 
Charming python sc2-8
byVladislav Ananev
 
8 встреча — Язык программирования Python (В. Ананьев)
bySmolensk Computer Science Club
 

Беглый обзор "внутренностей" Python

  • 1.
  • 2.
    Почему это можетбыть полезно? Часто у программиста, использующего в работе Python, возникает один из следующих вопросов: какой из двух способов решения проблемы потребляет меньше памяти? Беглый обзор “внутренностей” Python 2
  • 3.
    Почему это можетбыть полезно? Часто у программиста, использующего в работе Python, возникает один из следующих вопросов: какой из двух способов решения проблемы потребляет меньше памяти? какой из двух способов работает быстрее? Беглый обзор “внутренностей” Python 2
  • 4.
    Почему это можетбыть полезно? Часто у программиста, использующего в работе Python, возникает один из следующих вопросов: какой из двух способов решения проблемы потребляет меньше памяти? какой из двух способов работает быстрее? как поведет себя определенная конструкция при изменении runtime среды? Беглый обзор “внутренностей” Python 2
  • 5.
    Почему это можетбыть полезно? Решаются они обычно одним из следующих способов: можно спросить у коллег Беглый обзор “внутренностей” Python 3
  • 6.
    Почему это можетбыть полезно? Решаются они обычно одним из следующих способов: можно спросить у коллег можно найти ответ на StackOverflow Беглый обзор “внутренностей” Python 3
  • 7.
    Почему это можетбыть полезно? Решаются они обычно одним из следующих способов: можно спросить у коллег можно найти ответ на StackOverflow можно замерить самому Беглый обзор “внутренностей” Python 3
  • 8.
    Почему это можетбыть полезно? Однако понимание того, как работает интерпретатор на самых нижних уровнях, позволяет обрести интуитивное понимание нюансов работы многих конструкций языка. Беглый обзор “внутренностей” Python 4
  • 9.
    Почему это можетбыть полезно? Однако понимание того, как работает интерпретатор на самых нижних уровнях, позволяет обрести интуитивное понимание нюансов работы многих конструкций языка. Кроме того, в случае с Python абсолютное большинство программистов обладает достаточной квалификацией, чтобы без посредников найти ответ на свой вопрос в исходниках интерпретатора. Беглый обзор “внутренностей” Python 4
  • 10.
    Почему это можетбыть полезно? Знакомство с “внутренностями” полезно также потому, что Python является open source проектом - кто знает, быть может именно вы решите одну из наболевших проблем? ;) Беглый обзор “внутренностей” Python 5
  • 11.
    Почему это можетбыть полезно? Знакомство с “внутренностями” полезно также потому, что Python является open source проектом - кто знает, быть может именно вы решите одну из наболевших проблем? ;) Кратким изучением наиболее характерных особенностей интерпретатора мы сейчас и займемся. Беглый обзор “внутренностей” Python 5
  • 12.
    CPython Основная реализация Pythonна сегодняшний день Беглый обзор “внутренностей” Python 6
  • 13.
    CPython Основная реализация Pythonна сегодняшний день Написана на C (не С++), кроссплатформенна и довольно легко переносима на отличные от официально поддерживаемых платформы Беглый обзор “внутренностей” Python 6
  • 14.
    CPython Основная реализация Pythonна сегодняшний день Написана на C (не С++), кроссплатформенна и довольно легко переносима на отличные от официально поддерживаемых платформы Код простой и понятный Беглый обзор “внутренностей” Python 6
  • 15.
    CPython Основная реализация Pythonна сегодняшний день Написана на C (не С++), кроссплатформенна и довольно легко переносима на отличные от официально поддерживаемых платформы Код простой и понятный Нет, серьезно, простой и понятный, даже для людей, не интересующихся разработкой языков программирования ;) Беглый обзор “внутренностей” Python 6
  • 16.
    CPython Есть еще PyPy,IronPython, Jython, Boo (хотя это не совсем Python) Беглый обзор “внутренностей” Python 7
  • 17.
    CPython Есть еще PyPy,IronPython, Jython, Boo (хотя это не совсем Python) Они по своему интересны, но с CPython “внутри” у них мало общего Беглый обзор “внутренностей” Python 7
  • 18.
    CPython Есть еще PyPy,IronPython, Jython, Boo (хотя это не совсем Python) Они по своему интересны, но с CPython “внутри” у них мало общего Поэтому хотя они и могут быть очень полезны на практике, рассматривать их мы не будем Беглый обзор “внутренностей” Python 7
  • 19.
    Все - объект. Беглыйобзор “внутренностей” Python 8
  • 20.
    Все - объект ВPython все является объектом Беглый обзор “внутренностей” Python 9
  • 21.
    Все - объект ВPython все является объектом Ну то есть вообще все - от чисел до стакфреймов Беглый обзор “внутренностей” Python 9
  • 22.
    Все - объект ВPython все является объектом Ну то есть вообще все - от чисел до стакфреймов На C-уровне это выражено типом PyObject * Беглый обзор “внутренностей” Python 9
  • 23.
    Все - объект ВPython все является объектом Ну то есть вообще все - от чисел до стакфреймов На C-уровне это выражено типом PyObject * Любой PyObject имеет стандартный заголовок: #define PyObject_HEAD Py_ssize_t ob_refcnt; struct _typeobject *ob_type; Беглый обзор “внутренностей” Python 9
  • 24.
    Все - объект ВPython все является объектом Ну то есть вообще все - от чисел до стакфреймов На C-уровне это выражено типом PyObject * Любой PyObject имеет стандартный заголовок: #define PyObject_HEAD Py_ssize_t ob_refcnt; struct _typeobject *ob_type; Поэтому в 64-битном Python число не может быть меньше 24 байт. Deal with it. Беглый обзор “внутренностей” Python 9
  • 25.
    PyObject * #define PyObject_HEAD Py_ssize_t ob_refcnt; struct _typeobject *ob_type; ob_refcnt - reference counter ob_type - type object, определяющий поведение объекта и значение полей struct’а, идущих после заголовка (например, PyStringObject, PyIntObject) PyObject * - указатель. Поэтому все значения в Python передаются по ссылке. No exceptions. Беглый обзор “внутренностей” Python 10
  • 26.
    Ссылки PyIntTypeObject PyIntObject ob_refcnt = 3 ob_type ob_ival= 42 a b c >>> a = b = c = 42 Все три имени ссылаются на один объект Этот факт можно установить при помощи is В общем случае == и is не эквивалентны Беглый обзор “внутренностей” Python 11
  • 27.
    None None - особыйобъект Беглый обзор “внутренностей” Python 12
  • 28.
    None None - особыйобъект Он один на каждый инстанс интерпретатора. Совсем один. Беглый обзор “внутренностей” Python 12
  • 29.
    None None - особыйобъект Он один на каждый инстанс интерпретатора. Совсем один. Поэтому для него is и == всегда эквивалентны. Беглый обзор “внутренностей” Python 12
  • 30.
    None None - особыйобъект Он один на каждый инстанс интерпретатора. Совсем один. Поэтому для него is и == всегда эквивалентны. Вот так вот делать не стоит: if x == None: это медленно, бессмысленно и вообще плохой тон. Беглый обзор “внутренностей” Python 12
  • 31.
    int int - тип“малых” целых чисел Беглый обзор “внутренностей” Python 13
  • 32.
    int int - тип“малых” целых чисел В Python целые - неизменяемый тип Беглый обзор “внутренностей” Python 13
  • 33.
    int int - тип“малых” целых чисел В Python целые - неизменяемый тип Проверим как на них работает is: >>> int("100") is int("100") True >>> int("1000") is int("1000") False Беглый обзор “внутренностей” Python 13
  • 34.
    int int - тип“малых” целых чисел В Python целые - неизменяемый тип Проверим как на них работает is: >>> int("100") is int("100") True >>> int("1000") is int("1000") False Как это объяснить? Оказывается, интерпретатор “кеширует” объекты int со значениями от -5 до 256, для других значений создаются самостоятельные объекты. Беглый обзор “внутренностей” Python 13
  • 35.
    int int - тип“малых” целых чисел В Python целые - неизменяемый тип Проверим как на них работает is: >>> int("100") is int("100") True >>> int("1000") is int("1000") False Как это объяснить? Оказывается, интерпретатор “кеширует” объекты int со значениями от -5 до 256, для других значений создаются самостоятельные объекты. Поэтому список intов размером до байта будет иметь overhead в 8 байт на элемент (указатель), а больших intов - до 32 байт на элемент (указатель + объект). Беглый обзор “внутренностей” Python 13
  • 36.
    int Но загадки наэтом не заканчиваются: >>> (1000 is 1000, 1000+0 is 1000+0) (True, False) Беглый обзор “внутренностей” Python 14
  • 37.
    int Но загадки наэтом не заканчиваются: >>> (1000 is 1000, 1000+0 is 1000+0) (True, False) Почему так - немного дальше. Беглый обзор “внутренностей” Python 14
  • 38.
    string Строки, как ицелые, в Python неизменяемы Беглый обзор “внутренностей” Python 15
  • 39.
    string Строки, как ицелые, в Python неизменяемы Однако sharing объектов их затрагивает куда сильнее Беглый обзор “внутренностей” Python 15
  • 40.
    string Строки, как ицелые, в Python неизменяемы Однако sharing объектов их затрагивает куда сильнее Интерпретатор поддерживает dict так называемых interned строк, для каждой из которых гарантированно существует ровно один объект Беглый обзор “внутренностей” Python 15
  • 41.
    string Строки, как ицелые, в Python неизменяемы Однако sharing объектов их затрагивает куда сильнее Интерпретатор поддерживает dict так называемых interned строк, для каждой из которых гарантированно существует ровно один объект Все идентификаторы (имена переменных, модулей, методов), автоматически туда помещаются Беглый обзор “внутренностей” Python 15
  • 42.
    string Строки, как ицелые, в Python неизменяемы Однако sharing объектов их затрагивает куда сильнее Интерпретатор поддерживает dict так называемых interned строк, для каждой из которых гарантированно существует ровно один объект Все идентификаторы (имена переменных, модулей, методов), автоматически туда помещаются Оператор == для interned строк выраждается в is (сравнение указателей) Беглый обзор “внутренностей” Python 15
  • 43.
    string Строки, как ицелые, в Python неизменяемы Однако sharing объектов их затрагивает куда сильнее Интерпретатор поддерживает dict так называемых interned строк, для каждой из которых гарантированно существует ровно один объект Все идентификаторы (имена переменных, модулей, методов), автоматически туда помещаются Оператор == для interned строк выраждается в is (сравнение указателей) Помимо этого, по аналогии с int со значениями [−5, 256] разделяются объекты пустой и всех возможных однобуквенных строк Беглый обзор “внутренностей” Python 15
  • 44.
    Краткий вывод Не используйтеis для чего-то кроме None Беглый обзор “внутренностей” Python 16
  • 45.
    Краткий вывод Не используйтеis для чего-то кроме None Unless you know what you’re doing Беглый обзор “внутренностей” Python 16
  • 46.
  • 47.
    Виртуальная машина “Железный” процессорне может напрямую выполнять код на C Беглый обзор “внутренностей” Python 18
  • 48.
    Виртуальная машина “Железный” процессорне может напрямую выполнять код на C Его сначала нужно “разжевать” до очень простых операций, работающих с адресами и регистрами Беглый обзор “внутренностей” Python 18
  • 49.
    Виртуальная машина “Железный” процессорне может напрямую выполнять код на C Его сначала нужно “разжевать” до очень простых операций, работающих с адресами и регистрами Код на Python также не годится для непосредственного исполнения Беглый обзор “внутренностей” Python 18
  • 50.
    Виртуальная машина “Железный” процессорне может напрямую выполнять код на C Его сначала нужно “разжевать” до очень простых операций, работающих с адресами и регистрами Код на Python также не годится для непосредственного исполнения Поэтому скрипт при загрузке транслируется в байткод виртуальной машины Беглый обзор “внутренностей” Python 18
  • 51.
    Виртуальная машина “Железный” процессорне может напрямую выполнять код на C Его сначала нужно “разжевать” до очень простых операций, работающих с адресами и регистрами Код на Python также не годится для непосредственного исполнения Поэтому скрипт при загрузке транслируется в байткод виртуальной машины Виртуальная машина (VM) - это подпрограмма интерпретатора, испоняющая байткод. Беглый обзор “внутренностей” Python 18
  • 52.
    Виртуальная машина “Железный” процессорне может напрямую выполнять код на C Его сначала нужно “разжевать” до очень простых операций, работающих с адресами и регистрами Код на Python также не годится для непосредственного исполнения Поэтому скрипт при загрузке транслируется в байткод виртуальной машины Виртуальная машина (VM) - это подпрограмма интерпретатора, испоняющая байткод. Но кроме отсутствия “железного” воплощения, концептуальных различий с процессором нет. Беглый обзор “внутренностей” Python 18
  • 53.
    Байткод Команды CPython VMкодируются одним байтом Беглый обзор “внутренностей” Python 19
  • 54.
    Байткод Команды CPython VMкодируются одним байтом Каждая из них может иметь опциональный 16-битный аргумент Беглый обзор “внутренностей” Python 19
  • 55.
    Байткод Команды CPython VMкодируются одним байтом Каждая из них может иметь опциональный 16-битный аргумент Концептуально VM является стековой машиной (уместны аналогии с обратной польской записью и языком Forth) - значения кладутся на value stack (не путать с call stack), операции их снимают с вершины и кладут результат обратно. Беглый обзор “внутренностей” Python 19
  • 56.
    Байткод Команды CPython VMкодируются одним байтом Каждая из них может иметь опциональный 16-битный аргумент Концептуально VM является стековой машиной (уместны аналогии с обратной польской записью и языком Forth) - значения кладутся на value stack (не путать с call stack), операции их снимают с вершины и кладут результат обратно. При помощи модуля dis можно посмотреть на байткод “живых” функций Беглый обзор “внутренностей” Python 19
  • 57.
    def f(): a =1 b = 2 c = 3 return a + b * c 2 0 LOAD_CONST 1 (1) 3 STORE_FAST 0 (a) 3 6 LOAD_CONST 2 (2) 9 STORE_FAST 1 (b) 4 12 LOAD_CONST 3 (3) 15 STORE_FAST 2 (c) 5 18 LOAD_FAST 0 (a) 21 LOAD_FAST 1 (b) 24 LOAD_FAST 2 (c) 27 BINARY_MULTIPLY 28 BINARY_ADD 29 RETURN_VALUE Беглый обзор “внутренностей” Python 20
  • 58.
    Константы def f(): return(1,"abc", 3.0) Беглый обзор “внутренностей” Python 21
  • 59.
    Константы def f(): return(1,"abc", 3.0) >>> dis.dis(f) 2 0 LOAD_CONST 4 ((1, ’abc’, 3.0)) 3 RETURN_VALUE Беглый обзор “внутренностей” Python 21
  • 60.
    Константы def f(): return(1,"abc", 3.0) >>> dis.dis(f) 2 0 LOAD_CONST 4 ((1, ’abc’, 3.0)) 3 RETURN_VALUE >>> f.__code__.co_consts (None, 1, ’abc’, 3.0, (1, ’abc’, 3.0)) Беглый обзор “внутренностей” Python 21
  • 61.
    Code object Как мывидим, байткод это не просто строка байт, так как 16-битных целых недостаточно, чтобы кодировать любые Python-объекты Беглый обзор “внутренностей” Python 22
  • 62.
    Code object Как мывидим, байткод это не просто строка байт, так как 16-битных целых недостаточно, чтобы кодировать любые Python-объекты Однако их достаточно, чтобы кодировать смещения. Например, в список констант co_consts Беглый обзор “внутренностей” Python 22
  • 63.
    Code object Как мывидим, байткод это не просто строка байт, так как 16-битных целых недостаточно, чтобы кодировать любые Python-объекты Однако их достаточно, чтобы кодировать смещения. Например, в список констант co_consts Наряду с другой метаинформацией (количество локальных переменных, количество параметров, глубина стека) байткод формирует code object Беглый обзор “внутренностей” Python 22
  • 64.
    Code object Как мывидим, байткод это не просто строка байт, так как 16-битных целых недостаточно, чтобы кодировать любые Python-объекты Однако их достаточно, чтобы кодировать смещения. Например, в список констант co_consts Наряду с другой метаинформацией (количество локальных переменных, количество параметров, глубина стека) байткод формирует code object Именно code object являет собой единицу существования компилированного кода в Python Беглый обзор “внутренностей” Python 22
  • 65.
    Code object Как мывидим, байткод это не просто строка байт, так как 16-битных целых недостаточно, чтобы кодировать любые Python-объекты Однако их достаточно, чтобы кодировать смещения. Например, в список констант co_consts Наряду с другой метаинформацией (количество локальных переменных, количество параметров, глубина стека) байткод формирует code object Именно code object являет собой единицу существования компилированного кода в Python Они же сериализуются в .pyc файлы Беглый обзор “внутренностей” Python 22
  • 66.
    Code object code objectявляются неизменяемыми Беглый обзор “внутренностей” Python 23
  • 67.
    Code object code objectявляются неизменяемыми В “нормальном” коде они строятся единожды - при загрузке модуля Беглый обзор “внутренностей” Python 23
  • 68.
    Code object code objectявляются неизменяемыми В “нормальном” коде они строятся единожды - при загрузке модуля Это такой же объект как и все: def f(): def g(): pass return g 2 0 LOAD_CONST 1 (<code object f ...>) 3 MAKE_FUNCTION 0 6 STORE_FAST 0 (f) 3 9 LOAD_GLOBAL 0 (g) 12 RETURN_VALUE Беглый обзор “внутренностей” Python 23
  • 69.
    Компиляция Процесс преобразования исходногокода модуля в набор code object называется компиляцией Беглый обзор “внутренностей” Python 24
  • 70.
    Компиляция Процесс преобразования исходногокода модуля в набор code object называется компиляцией Однако компилятор у Python очень рудиментарный - фактически 1-в-1 отображение конструкций в байткод Беглый обзор “внутренностей” Python 24
  • 71.
    Компиляция Процесс преобразования исходногокода модуля в набор code object называется компиляцией Однако компилятор у Python очень рудиментарный - фактически 1-в-1 отображение конструкций в байткод Оптимизаций уровня байткода почти нет Беглый обзор “внутренностей” Python 24
  • 72.
    Компиляция Процесс преобразования исходногокода модуля в набор code object называется компиляцией Однако компилятор у Python очень рудиментарный - фактически 1-в-1 отображение конструкций в байткод Оптимизаций уровня байткода почти нет uncompyle, open source декомпилятор Python, способен восстановить исходный код по .pyc файлу почти всегда, потеряв при этом разве что комментарии Беглый обзор “внутренностей” Python 24
  • 73.
    Компиляция Процесс преобразования исходногокода модуля в набор code object называется компиляцией Однако компилятор у Python очень рудиментарный - фактически 1-в-1 отображение конструкций в байткод Оптимизаций уровня байткода почти нет uncompyle, open source декомпилятор Python, способен восстановить исходный код по .pyc файлу почти всегда, потеряв при этом разве что комментарии Так как компилятор неоптимизирующий, ему почти всегда можно помочь (если надо) Беглый обзор “внутренностей” Python 24
  • 74.
    Компиляция def f(): l =[] for i in xrange(10000): l.append(i) >>> timeit.timeit("""....""") 0.09371685981750488 >>> dis.dis(f) (... оставлено только тело цикла ...) 4 25 LOAD_FAST 0 (l) 28 LOAD_ATTR 1 (append) 31 LOAD_FAST 1 (i) 34 CALL_FUNCTION 1 Беглый обзор “внутренностей” Python 25
  • 75.
    Loop hoisting LOAD_ATTR поидее выполняется небыстро - это поиск строки с именем метода в дикте (хеш-таблице). Строка interned, но все равно это долго. Беглый обзор “внутренностей” Python 26
  • 76.
    Loop hoisting LOAD_ATTR поидее выполняется небыстро - это поиск строки с именем метода в дикте (хеш-таблице). Строка interned, но все равно это долго. Логично не выполнять эту операцию в теле цикла, а сделать ее единожды до начала выполнения. Беглый обзор “внутренностей” Python 26
  • 77.
    Loop hoisting LOAD_ATTR поидее выполняется небыстро - это поиск строки с именем метода в дикте (хеш-таблице). Строка interned, но все равно это долго. Логично не выполнять эту операцию в теле цикла, а сделать ее единожды до начала выполнения. Эта оптимизация известна как loop hoisting, но рудиментарный компилятор Python ее не делает. Беглый обзор “внутренностей” Python 26
  • 78.
    Loop hoisting LOAD_ATTR поидее выполняется небыстро - это поиск строки с именем метода в дикте (хеш-таблице). Строка interned, но все равно это долго. Логично не выполнять эту операцию в теле цикла, а сделать ее единожды до начала выполнения. Эта оптимизация известна как loop hoisting, но рудиментарный компилятор Python ее не делает. Поможем ему! Беглый обзор “внутренностей” Python 26
  • 79.
    Loop hoisting def f(): l= [] la = l.append for i in xrange(10000): la(i) >>> timeit.timeit("""....""") 0.08451047520987543 >>> dis.dis(f) (... оставлено только тело цикла ...) 5 34 LOAD_FAST 1 (la) 37 LOAD_FAST 2 (i) 40 CALL_FUNCTION 1 До оптимизации было 0.09371685981750488. Разница - 10%. Беглый обзор “внутренностей” Python 27
  • 80.
    LIST_APPEND Добавление к списку- частая операция, и потому в CPython VM есть особый опкод LIST_APPEND Беглый обзор “внутренностей” Python 28
  • 81.
    LIST_APPEND Добавление к списку- частая операция, и потому в CPython VM есть особый опкод LIST_APPEND Как показывает изучение исходников компилятора, используется этот опкод только для компиляции list comprehensions: def f(): return [x for x in xrange(10000)] >>> timeit.timeit("""....""") 0.08152854398842842 >>> dis.dis(f) (... оставлено только тело цикла ...) 16 STORE_FAST 0 (x) 19 LOAD_FAST 0 (x) 22 LIST_APPEND 2 Беглый обзор “внутренностей” Python 28
  • 82.
  • 83.
    Дикты и строки Многиезнакомые с семантикой Python люди шутят, что Гвидо ван Россум написал dict (открытую хеш-таблицу) и string (неизменяемые строки), после чего решил больше ничего не писать Беглый обзор “внутренностей” Python 30
  • 84.
    Дикты и строки Многиезнакомые с семантикой Python люди шутят, что Гвидо ван Россум написал dict (открытую хеш-таблицу) и string (неизменяемые строки), после чего решил больше ничего не писать Действительно, объекты, модули и неймспейсы - все это обычные дикты cо строковыми ключами Беглый обзор “внутренностей” Python 30
  • 85.
    Дикты и строки Многиезнакомые с семантикой Python люди шутят, что Гвидо ван Россум написал dict (открытую хеш-таблицу) и string (неизменяемые строки), после чего решил больше ничего не писать Действительно, объекты, модули и неймспейсы - все это обычные дикты cо строковыми ключами Глобальное пространство имен модуля, следовательно, тоже дикт, а обращение к переменной - это lookup в дикте. Беглый обзор “внутренностей” Python 30
  • 86.
    Дикты и строки Многиезнакомые с семантикой Python люди шутят, что Гвидо ван Россум написал dict (открытую хеш-таблицу) и string (неизменяемые строки), после чего решил больше ничего не писать Действительно, объекты, модули и неймспейсы - все это обычные дикты cо строковыми ключами Глобальное пространство имен модуля, следовательно, тоже дикт, а обращение к переменной - это lookup в дикте. Всегда ли это так? Беглый обзор “внутренностей” Python 30
  • 87.
    Дикты и строки deff(): a = 3 return a + b 2 0 LOAD_CONST 1 (1) 3 STORE_FAST 0 (a) 3 6 LOAD_FAST 0 (a) 9 LOAD_GLOBAL 0 (b) 12 BINARY_ADD 13 RETURN_VALUE Беглый обзор “внутренностей” Python 31
  • 88.
    LOAD_FAST и LOAD_GLOBAL 36 LOAD_FAST 0 (a) 9 LOAD_GLOBAL 0 (b) Для имен a и b компилятор использовал разные опкоды. Почему? Беглый обзор “внутренностей” Python 32
  • 89.
    LOAD_FAST и LOAD_GLOBAL 36 LOAD_FAST 0 (a) 9 LOAD_GLOBAL 0 (b) Для имен a и b компилятор использовал разные опкоды. Почему? Оказывается, на этапе компиляции в code object собираются все имена локальных переменных (то есть присваиваемые в этом блоке кода и не помеченные явно при помощи global), и заносятся в список co_locals. Беглый обзор “внутренностей” Python 32
  • 90.
    LOAD_FAST и LOAD_GLOBAL 36 LOAD_FAST 0 (a) 9 LOAD_GLOBAL 0 (b) Для имен a и b компилятор использовал разные опкоды. Почему? Оказывается, на этапе компиляции в code object собираются все имена локальных переменных (то есть присваиваемые в этом блоке кода и не помеченные явно при помощи global), и заносятся в список co_locals. Впоследствии для каждого фрейма стека создается массив локальных переменных, и обращение к ним происходит по их индексу в co_locals. Этот индекс неизменен и “зашит” в байткод. Беглый обзор “внутренностей” Python 32
  • 91.
    LOAD_FAST и LOAD_GLOBAL LOAD_FAST,как нетрудно догадаться, просто берет значение по индексу из массива Беглый обзор “внутренностей” Python 33
  • 92.
    LOAD_FAST и LOAD_GLOBAL LOAD_FAST,как нетрудно догадаться, просто берет значение по индексу из массива LOAD_GLOBAL же вынужден брать строку с именем из co_consts, после чего искать по этому ключу в дикте неймспейса Беглый обзор “внутренностей” Python 33
  • 93.
    LOAD_FAST и LOAD_GLOBAL LOAD_FAST,как нетрудно догадаться, просто берет значение по индексу из массива LOAD_GLOBAL же вынужден брать строку с именем из co_consts, после чего искать по этому ключу в дикте неймспейса Обе операции выполняются с ожидаемой стоимостью O(1), но у массива константа явно лучше Беглый обзор “внутренностей” Python 33
  • 94.
    LOAD_FAST и LOAD_GLOBAL LOAD_FAST,как нетрудно догадаться, просто берет значение по индексу из массива LOAD_GLOBAL же вынужден брать строку с именем из co_consts, после чего искать по этому ключу в дикте неймспейса Обе операции выполняются с ожидаемой стоимостью O(1), но у массива константа явно лучше Поэтому закешировать что-то в локальную переменную не самая плохая идея в плане производительности Беглый обзор “внутренностей” Python 33
  • 95.
    Lexical scoping Глобальный илокальный неймспейсы достаточно очевидны сами по себе Беглый обзор “внутренностей” Python 34
  • 96.
    Lexical scoping Глобальный илокальный неймспейсы достаточно очевидны сами по себе Однако Python позволяет делать вот так: def f(): a = 1 def g(): return a return g >>> t = f() >>> t() 1 Беглый обзор “внутренностей” Python 34
  • 97.
    Lexical scoping Глобальный илокальный неймспейсы достаточно очевидны сами по себе Однако Python позволяет делать вот так: def f(): a = 1 def g(): return a return g >>> t = f() >>> t() 1 Как возвращенной функции удается вернуть значение из разрушенного фрейма? Беглый обзор “внутренностей” Python 34
  • 98.
    Lexical scoping Оказывается, такаяситуация детектируется при компиляции и решается при помощи создания cell object (в функциональных языках подобные объекты называют замыканиями или closures): 2 0 LOAD_CONST 1 (1) 3 STORE_DEREF 0 (a) 3 6 LOAD_CLOSURE 0 (a) 9 BUILD_TUPLE 1 12 LOAD_CONST 2 (<code object ...>) 15 MAKE_CLOSURE 0 18 STORE_FAST 0 (g) 4 21 LOAD_FAST 0 (g) 24 RETURN_VALUE Беглый обзор “внутренностей” Python 35
  • 99.
    Lexical scoping Оказывается, такаяситуация детектируется при компиляции и решается при помощи создания cell object (в функциональных языках подобные объекты называют замыканиями или closures): 2 0 LOAD_CONST 1 (1) 3 STORE_DEREF 0 (a) 3 6 LOAD_CLOSURE 0 (a) 9 BUILD_TUPLE 1 12 LOAD_CONST 2 (<code object ...>) 15 MAKE_CLOSURE 0 18 STORE_FAST 0 (g) 4 21 LOAD_FAST 0 (g) 24 RETURN_VALUE cell object - это код функции вместе со значениями “внешних” (свободных, free) переменных Беглый обзор “внутренностей” Python 35
  • 100.
    Lexical scoping cell objectпо времени жизни не привязан к фрейму, в котором он создан, и собирается сборщиком мусора только тогда, когда станет недостижим. Беглый обзор “внутренностей” Python 36
  • 101.
    Lexical scoping cell objectпо времени жизни не привязан к фрейму, в котором он создан, и собирается сборщиком мусора только тогда, когда станет недостижим. Это “взрослая” реализация лексической области видимости Беглый обзор “внутренностей” Python 36
  • 102.
    Lexical scoping cell objectпо времени жизни не привязан к фрейму, в котором он создан, и собирается сборщиком мусора только тогда, когда станет недостижим. Это “взрослая” реализация лексической области видимости Однако, к сожалению, она неполна: def f(): a = 1 if True: a = 2; print a print a этот код выведет 2 2. Аналогичный код на C++, или, скажем, Lua, выдаст 2 1 Беглый обзор “внутренностей” Python 36
  • 103.
    Lexical scoping cell objectпо времени жизни не привязан к фрейму, в котором он создан, и собирается сборщиком мусора только тогда, когда станет недостижим. Это “взрослая” реализация лексической области видимости Однако, к сожалению, она неполна: def f(): a = 1 if True: a = 2; print a print a этот код выведет 2 2. Аналогичный код на C++, или, скажем, Lua, выдаст 2 1 Это источник трудноуловимых багов Беглый обзор “внутренностей” Python 36
  • 104.
    Выстрелить в ногу! Чтовыведет это код? l = [lambda: x for x in "abcdefg"] for r in l: print r(), Беглый обзор “внутренностей” Python 37
  • 105.
    Выстрелить в ногу! Чтовыведет это код? l = [lambda: x for x in "abcdefg"] for r in l: print r(), Наверное a b c d e f g? Беглый обзор “внутренностей” Python 37
  • 106.
    Выстрелить в ногу! Чтовыведет это код? l = [lambda: x for x in "abcdefg"] for r in l: print r(), Наверное a b c d e f g? Реальность жестока. Беглый обзор “внутренностей” Python 37
  • 107.
    Выстрелить в ногу! Чтовыведет это код? l = [lambda: x for x in "abcdefg"] for r in l: print r(), Наверное a b c d e f g? Реальность жестока. Правильный ответ - g g g g g g g. Беглый обзор “внутренностей” Python 37
  • 108.
    Lexical scoping К сожалению,различие поведения областей видимости на макро- и микроуровнях настолько глубоко зашито в архитектуре языка, что поправить его практически нереально Беглый обзор “внутренностей” Python 38
  • 109.
    Lexical scoping К сожалению,различие поведения областей видимости на макро- и микроуровнях настолько глубоко зашито в архитектуре языка, что поправить его практически нереально Даже если это сделать - это с большой вероятностью приведет к “ломанию” имеющегося кода Беглый обзор “внутренностей” Python 38
  • 110.
    Lexical scoping К сожалению,различие поведения областей видимости на макро- и микроуровнях настолько глубоко зашито в архитектуре языка, что поправить его практически нереально Даже если это сделать - это с большой вероятностью приведет к “ломанию” имеющегося кода Поэтому про данную особенность надо просто помнить, и не сильно увлекаться функциональным программированием на Python ;) Беглый обзор “внутренностей” Python 38
  • 111.
  • 112.
    Заключение К сожалению, регламентданного доклада не дает слишком разогнаться. За бортом остаются многие интересные темы: Беглый обзор “внутренностей” Python 40
  • 113.
    Заключение К сожалению, регламентданного доклада не дает слишком разогнаться. За бортом остаются многие интересные темы: Global Interpreter Lock (GIL), или почему программы на Python на нескольких ядрах работают медленнее, чем на одном Беглый обзор “внутренностей” Python 40
  • 114.
    Заключение К сожалению, регламентданного доклада не дает слишком разогнаться. За бортом остаются многие интересные темы: Global Interpreter Lock (GIL), или почему программы на Python на нескольких ядрах работают медленнее, чем на одном frame object и их список, или как greenlet умудряется эмулировать кооперативную многозадачность “срезанием” стека Беглый обзор “внутренностей” Python 40
  • 115.
    Заключение К сожалению, регламентданного доклада не дает слишком разогнаться. За бортом остаются многие интересные темы: Global Interpreter Lock (GIL), или почему программы на Python на нескольких ядрах работают медленнее, чем на одном frame object и их список, или как greenlet умудряется эмулировать кооперативную многозадачность “срезанием” стека ООП в Python, или почему у object нельзя выставить атрибут, а у унаследованного от него пустого класса - можно Беглый обзор “внутренностей” Python 40
  • 116.
    Заключение К сожалению, регламентданного доклада не дает слишком разогнаться. За бортом остаются многие интересные темы: Global Interpreter Lock (GIL), или почему программы на Python на нескольких ядрах работают медленнее, чем на одном frame object и их список, или как greenlet умудряется эмулировать кооперативную многозадачность “срезанием” стека ООП в Python, или почему у object нельзя выставить атрибут, а у унаследованного от него пустого класса - можно Генераторы, или как “шаманство” с фреймами позволяет создавать видимость их (генераторов) наличия, но с серьезными ограничениями Беглый обзор “внутренностей” Python 40
  • 117.
    Заключение Однако большой проблемынет - это не сакральное знание Беглый обзор “внутренностей” Python 41
  • 118.
    Заключение Однако большой проблемынет - это не сакральное знание Все, что я вам сегодня рассказал, я не прочитал в интернете и на StackOverflow - я прочитал это в исходных кодах интерпретатора Беглый обзор “внутренностей” Python 41
  • 119.
    Заключение Однако большой проблемынет - это не сакральное знание Все, что я вам сегодня рассказал, я не прочитал в интернете и на StackOverflow - я прочитал это в исходных кодах интерпретатора Они действительно неплохо структурированы и их довольно просто читать, даже людям без соответствующего бэкграунда Беглый обзор “внутренностей” Python 41
  • 120.
    Заключение Однако большой проблемынет - это не сакральное знание Все, что я вам сегодня рассказал, я не прочитал в интернете и на StackOverflow - я прочитал это в исходных кодах интерпретатора Они действительно неплохо структурированы и их довольно просто читать, даже людям без соответствующего бэкграунда Мне это помогло глубже понять как работает тот код, который я пишу, что порой оказывалось очень полезным при профайлинге критичных мест Беглый обзор “внутренностей” Python 41
  • 121.
    Заключение Однако большой проблемынет - это не сакральное знание Все, что я вам сегодня рассказал, я не прочитал в интернете и на StackOverflow - я прочитал это в исходных кодах интерпретатора Они действительно неплохо структурированы и их довольно просто читать, даже людям без соответствующего бэкграунда Мне это помогло глубже понять как работает тот код, который я пишу, что порой оказывалось очень полезным при профайлинге критичных мест Это как раз тот случай, когда вместо того, чтобы лезть на StackOverflow, полезнее и интереснее разобраться самому. Так что дерзайте! Беглый обзор “внутренностей” Python 41
  • 122.
  • 123.