На чем написан интерпретатор python
Почему существует так много Питонов?
Удивительно, но это довольно неоднозначное заявление. Что я имею ввиду под “Питоном”? Может, абстрактный интерфейс Питона? Или CPython, распространенная реализация Питона (не путать с похожим по названию Cython)? Или я имею ввиду что-то совсем иное? Может, я косвенно ссылаюсь на Jython, или IronPython, или PyPy. Или может я отвлекся так сильно, что говорю о RPython или RubyPython (которые очень сильно отличаются).
Не смотря на схожесть в названиях указанных выше технологий, некоторые из них имеют совсем другие задачи (или, как минимум, работают совершенно иными способами)
При работе с Питоном я столкнулся с кучей таких технологий. Инструменты *ython. Но лишь недавно я уделил время, чтобы разобраться, что они собой представляют, как они работают и почему они (каждая по-своему) необходимы.
В этом посте я начну с нуля и пройдусь по разным реализациям Питона, а закончу подробным введением в PyPy, за которым, по моему мнению, будущее языка.
Все начинается с понимания того, чем на самом деле является “Питон”.
Если у вас хорошее понимание машинного кода, виртуальных машин и так далее, можете пропустить этот раздел.
Питон интерпретируемый или компилируемый?
Это распространенный источник непонимания среди новичков Питона.
Первое, что необходимо понять: “Питон” – это интерфейс. Существует спецификация, описывающая, что должен делать Питон, и как он должен себя вести (что справедливо для любого интерфейса). И существует несколько имплементаций (что также справедливо для любого интерфейса).
Второе: “интерпретируемый” и “компилируемый” это свойства имплементации, но не интерфейса.
Так что сам вопрос не совсем корректен.
В случае с самой распространенной реализацией (CPython: написанный на C, часто называемый просто “Python”, и, конечно, именно тот, который вы используете, если понятия не имеете о чем я толкую) ответ: интерпретируемый, с некоторой компиляцией. CPython компилирует* исходный код на Питоне в байткод, а затем интерпретирует этот байткод, запуская его в процессе.
* Замечание: это не совсем “компиляция” в традиционном смысле. Обычно, мы считаем, что “компиляция” это конвертация из высокоуровневого языка в машинный код. Тем не менее – в некотором роде это “компиляция”.
Давайте изучим этот ответ получше, так как он поможет нам понять некоторые концепции, ожидающие нас в этой статье.
Байткод или машинный код
Очень важно понять разницу между байткодом и машинным (или нативным) кодом. Пожалуй, легче всего ее понять на примере:
— Cи компилируется в машинный код, который впоследствии запускается напрямую процессором. Каждая инструкция заставляет процессор производить разные действия.
— Java компилируется в байткод, который впоследствии запускается на Виртуальной машине Java (Java Virtual Machine, JVM), абстрактном компьютере, который запускает программы. Каждая инструкция обрабатывается JVM, который взаимодействует с компьютером.
Сильно упрощая: машинный код намного быстрее, но байткод лучше переносим и защищен.
Машинный код может отличаться в зависимости от машины, тогда как байткод одинаковый на всех машинах. Можно сказать, что машинный код оптимизирован под вашу конфигурацию.
Возвращаясь к CPython, цепочка операций выглядит следующим образом:
1. CPython компилирует ваш исходный код на Питоне в байткод.
2. Этот байткод запускается на виртуальной машине CPython.
Альтернативные виртуальные машины: Jython, IronPython и другие
Как я говорил выше, у Питона существует несколько реализаций. Опять же, как говори-лось выше, самой популярной является CPython. Эта версия Питона написана на C и считается имплементацией “по умолчанию”.
Но как насчет альтернатив? Одна из наиболее видных это Jython, реализация Питона на Java, которая использует JVM. В то время как CPython генерирует байткод для запуска на CPython VM, Jython генерирует байткод Java для запуска на JVM (это то же самое, что генерируется при компиляции программы на Java).
“Зачем может понадобиться использовать альтернативную реализацию?”, спросите вы. Ну, для начала, разные реализации хорошо ладят с разными наборами технологий.
CPython упрощает написание C-расширений для кода на Питоне потому что в конце он запускается интерпретатором Cи. Jython в свою очередь упрощает работу с другими программами на Java: вы можете импортировать любые Java-классы без дополнительных усилий, призывая и используя ваши Java-классы из программ на Jython. (Замечание: если вы еще не думали об этом всерьез, это довольно безумно. Мы дожили до того времени, когда можно смешивать разные языки и компилировать их в одну сущность. Как заметил Rostin, программы, смешивающие код на Фортране с Cи появились довольно давно, так что это не совсем новинка. Но это все же круто.)
В качестве примера, вот корректный код на Jython:
[Java HotSpot(TM) 64-Bit Server VM (Apple Inc.)] on java1.6.0_51
>>> from java.util import HashSet
>>> s = HashSet(5)
>>> s.add(«Foo»)
>>> s.add(«Bar»)
>>> s
[Foo, Bar]
Можно сказать, что Jython: Java :: IronPython: C#. Они работают на соответствующих виртуальных машинах, есть возможность импортировать классы C# в код IronPython и классы Java в код Jython, и так далее.
Кстати, хоть это и не станет причиной для перехода на другую имплементацию, стоит упомянуть, что имплементации эти на самом деле отличаются поведением. Это касается не только способов интерпретации кода на Питоне. Однако эти отличия, как правило, не-значительны, они исчезают и появляются со временем из-за активной разработки. К примеру, IronPython использует строки Unicode по умолчанию; однако CPython использует ASCII в версиях 2.x (выдавая ошибку UnicodeEncodeError для не-ASCII символов), и при этом поддерживает символы Unicode по умолчанию в версиях 3.x.
Компиляция на лету (Just-in-Time Compilation): PyPy и будущее
Итак, у нас есть имплементация Питона, написанная на Си, еще одна – на Java, и третья на C#. Следующий логичный шаг: имплементация Питона, написанная на… Питоне. (Подготовленный читатель заметит, что это утверждение немного обманчиво).
Вот почему это может сбивать с толку. Для начала, давайте обсудим компиляцию на лету (just-in-time или JIT).
JIT. Почему и как
Напомню, что нативный машинный код намного быстрее байткода. Ну, а что, если бы можно было компилировать часть байткода и запускать его как нативный код? Пришлось бы “заплатить” некоторую цену (иными словами: время) за компиляцию байткода, но если результат будет работать быстрее, то это здорово! Этим и мотивируется JIT-компиляция, гибридная техника, которая совмещает в себе преимущества интерпретато-ров и компиляторов. В двух словах – JIT старается использовать компиляцию, чтобы ускорить систему интерпретации.
Например, вот распространенный подход JIT:
В этом вся суть PyPy: использовать JIT в Питоне (в дополнении можно найти предыдущие попытки). Конечно, есть и другие цели: PyPy нацелен на кроссплатформенность, работу с небольшим количеством памяти и поддержку stackless (отказа от стека вызовов языка Си в пользу собственного стека). Но JIT это главное преимущество. В среднем на основе временных тестов, фактор ускорения составляет 6.27. Более подробные данные можно получить из схемы от PyPy Speed Center:
В PyPy сложно разобраться
У PyPy есть огромный потенциал, и в данный момент он хорошо совместим с CPython (так что на нем можно запускать Flask, Django, и т.д.).
Но с PyPy есть много путаницы. (оцените, к примеру, это бессмысленное предложение создать PyPyPy…). По моему мнению основная причина в том, что PyPy одновременно является:
1. Интерпретатором Питона, написанным на RPython (не Python (я обманул вас до этого)). RPython это подмножество Python со статичной типизацией. В Python, вести тщательные беседы о типах “в целом невозможно” почему это так сложно? рассмотрите следующее:
x = random.choice([1, «foo»])
это корректный код на Python (спасибо Ademan‘у). Какой тип у x? Как мы можем обсуждать типы переменных, когда типы даже не форсируются?). В RPython мы жертвуем некоторой гибкостью, но взамен получаем возможность гораздо проще управлять памятью и много чего еще, что помогает при оптимизации.
2. Компилятором, который компилирует код на RPython в разные форматы и поддерживает JIT. Платформой по-умолчанию является Си, то есть компилятор RPython-в-Си, но в качестве целевой платформы также можно выбрать JVM и другие.
Для простоты описания, я буду называть их PyPy (1) и PyPy (2).
Зачем могут понадобиться эти две вещи, и почему – в одном наборе? Думайте об этом так: PyPy (1) это интерпретатор, написанный на RPython. То есть он берет пользовательский код на Питоне и компилирует его в байткод. Но чтобы сам интерпретатор (написанный на RPython) мог работать, он должен быть интерпретирован другой реализацией Пи-тона, верно?
Итак, можно просто использовать CPython чтобы запускать интерпретатор. Но это будет не слишком быстро.
Вместо этого мы используем PyPy (2) (называемый RPython Toolchain) чтобы компилировать интерпретатор PyPy в код для другой платформы (например, C, JVM, или CLI) для запуска на конечной машине, с добавлением JIT. Это волшебно: PyPy динамически добавляет JIT к интерпретатору, генерируя собственный компилятор! (Опять же, это безумие: мы компилируем интерпретатор, добавляя другой отдельный, самостоятельный компилятор).
В конце концов результатом будет самостоятельный исполняемый файл, который интерпретирует исходный код на Питоне и использует оптимизацию JIT. То, что нужно! Понять сложновато, но, возможно, эта схема поможет:
Повторим: настоящая красота PyPy в том, что мы можем написать себе кучу разных интерпретаторов Питона на RPython не волнуясь о JIT (не считая пары деталей). После этого PyPy реализует для нас JIT, используя RPython Toolchain/PyPy (2).
На самом деле, если копнуть глубже в абстракцию, теоретически можно написать интерпретатор любого языка, направить его в PyPy и получить JIT для этого языка. Это возможно потому, что PyPy концентрируется на оптимизации самого интерпретатора, а не деталей языка, который тот интерпретирует.
В качестве отступления я бы хотел заметить, что сам JIT совершенно восхитителен. Он использует технику под названием “отслеживание” (tracing), которая работает следующим образом:
Узнать больше можно из этой легкодоступной и очень интересной публикации.
Подытожим: мы используем PyPy-компилятор RPython-в-Си (или другую целевую плат-форму), чтобы скомпилировать реализованный на RPython интерпретататор PyPу.
Заключение
Почему все это так восхитительно? Почему стоит гнаться за этой безумной идеей? По-моему, Алекс Гейнор объяснил это очень хорошо в своем блоге: “[За PyPy будущее] потому что [он] более быстрый, более гибкий и является лучшей платформой для развития Питона”.
Дополнение: другие названия, которые вы, возможно, слышали
Python 3000 (Py3k): альтернативное название Python 3.0, основной релиз Питона с обратной совместимостью, который появился в 2008. году. Команда Py3k предсказала, что новой версии понадобится примерно пять лет чтобы полностью прижиться. И в то время, как большинство (внимание: надуманное утверждение) разработчиков на Питоне продолжают использовать Python 2.x, люди все больше задумываются о Py3k.
Numba: “специализированный just-in-time компилятор”, который добавляет JIT в снабженный примечаниями код на Питоне. Проще говоря, вы даете ему подсказки, а он ускоряет некоторые части вашего кода. Numba является частью дистрибутива Anaconda набора пакетов для анализа и управления данными.
IPython: сильно отличается от всего, что мы обсудили. Вычислительная среда для Питона. Интерактивная, с поддержкой GUI-пакетов, браузеров и так далее.
Psyco: модуль расширения Питона, одна из первых попыток Питона в области JIT. Давно помечен как “неподдерживаемый и мертвый”. Главный разработчик Psyco Армин Риго сейчас работает над PyPy.
Привязки к языкам
JavaScript фреймворки
Почему существует так много Питонов?
Питон изумителен.
Удивительно, но это довольно неоднозначное заявление. Что я имею ввиду под Питоном? Может, абстрактный интерфейс Питона? Или CPython, распространенная реализация Питона (не путать с похожим по названию Cython)? Или я имею ввиду что-то совсем иное? Может, я косвенно ссылаюсь на Jython, или IronPython, или PyPy. Или может я отвлекся так сильно, что говорю о RPython или RubyPython (которые очень сильно отличаются).
Не смотря на схожесть в названиях указанных выше технологий, некоторые из них имеют совсем другие задачи (или, как минимум, работают совершенно иными способами)
При работе с Питоном я столкнулся с кучей таких технологий. Инструменты *ython. Но лишь недавно я уделил время, чтобы разобраться, что они собой представляют, как они работают и почему они (каждая по-своему) необходимы.
В этом посте я начну с нуля и пройдусь по разным реализациям Питона, а закончу подробным введением в PyPy, за которым, по моему мнению, будущее языка.
В этом посте я начну с нуля и пройдусь по разным реализациям Питона, а закончу подробным введением в PyPy, за которым, по моему мнению, будущее языка.
Все начинается с понимания того, чем на самом деле является Питон.
Если у вас хорошее понимание машинного кода, виртуальных машин и так далее, можете пропустить этот раздел.
«Питон интерпретируемый или компилируемый?»
Это распространенный источник непонимания среди новичков Питона.
Первое, что необходимо понять: Питон – это интерфейс. Существует спецификация, описывающая, что должен делать Питон, и как он должен себя вести (что справедливо для любого интерфейса). И существует несколько имплементаций (что также справедливо для любого интерфейса).
Второе: «интерпретируемый» и «компилируемый» это свойства имплементации, но не интерфейса.
Так что сам вопрос не совсем корректен.
Питон интерпретируемый или компилируемый? Сам вопрос не совсем корректен.
В случае с самой распространенной реализацией (CPython: написанный на C, часто называемый просто Python, и, конечно, именно тот, который вы используете, если понятия не имеете о чем я толкую) ответ: интерпретируемый, с некоторой компиляцией. CPython компилирует* исходный код на Питоне в байткод, а затем интерпретирует этот байткод, запуская его в процессе.
* Замечание: это не совсем «компиляция» в традиционном смысле. Обычно, мы считаем, что «компиляция» – это конвертация из высокоуровневого языка в машинный код. Тем не менее – в некотором роде это «компиляция».
Давайте изучим этот ответ получше, так как он поможет нам понять некоторые концепции, ожидающие нас в этой статье.
Байткод или машинный код
Очень важно понять разницу между байткодом и машинным (или нативным) кодом. Пожалуй, легче всего ее понять на примере:
Сильно упрощая: машинный код намного быстрее, но байткод лучше переносим и защищен.
Машинный код может отличаться в зависимости от машины, тогда как байткод одинаковый на всех машин. Можно сказать, что машинный код оптимизирован под вашу конфигурацию.
Возвращаясь к CPython, цепочка операций выглядит следующим образом:
Альтернативные виртуальные машины: Jython, IronPython и другие
Как я говорил выше, у Питона существует несколько реализаций. Опять же, как говорилось выше, самой популярной является CPython. Эта версия Питона написана на C и считается имплементацией по умолчанию.
Но как насчет альтернатив? Одна из наиболее видных это Jython, реализация Питона на Java, которая использует JVM. В то время как CPython генерирует байткод для запуска на CPython VM, Jython генерирует байткод Java для запуска на JVM (это то же самое, что генерируется при компиляции программы на Java).
«Зачем может понадобиться использовать альтернативную реализацию?», – спросите вы. Ну, для начала, разные реализации хорошо ладят с разными наборами технологий.
CPython упрощает написание C-расширений для кода на Питоне потому что в конце он запускается интерпретатором Cи. Jython в свою очередь упрощает работу с другими программами на Java: вы можете импортировать любые Java-классы без дополнительных усилий, призывая и используя ваши Java-классы из программ на Jython. (Замечание: если вы еще не думали об этом всерьез, это довольно безумно. Мы дожили до того времени, когда можно смешивать разные языки и компилировать их в одну сущность. Как заметил Rostin, программы, смешивающие код на Фортране с Cи появились довольно давно, так что это не совсем новинка. Но это все же круто.)
В качестве примера, вот корректный код на Jython:
Можно сказать, что Jython : Java :: IronPython : C#. Они работают на соответствующих виртуальных машинах, есть возможность импортировать классы C# в код IronPython и классы Java в код Jython, и так далее.
Кстати, хоть это и не станет причиной для перехода на другую имплементацию, стоит упомянуть, что имплементации эти на самом деле отличаются поведением. Это касается не только способов интерпретации кода на Питоне. Однако эти отличия, как правило, незначительны, они исчезают и появляются со временем из-за активной разработки. К примеру, IronPython использует строки Unicode по умолчанию; однако CPython использует ASCII в версиях 2.x (выдавая ошибку UnicodeEncodeError для не-ASCII символов), и при этом поддерживает символы Unicode по умолчанию в версиях 3.x.
Компиляция на лету (Just-in-Time Compilation): PyPy и будущее
Итак, у нас есть имплементация Питона, написанная на Си, еще одна – на Java, и третья на C#. Следующий логичный шаг: имплементация Питона, написанная на… Питоне. (Подготовленный читатель заметит, что это утверждение немного обманчиво).
Вот почему это может сбивать с толку. Для начала, давайте обсудим компиляцию на лету (just-in-time или JIT).
JIT Почему и как
Напомню, что нативный машинный код намного быстрее байткода. Ну, а что, если бы можно было компилировать часть байткода и запускать его как нативный код? Пришлось бы «заплатить» некоторую цену (иными словами: время) за компиляцию байткода, но если результат будет работать быстрее, то это здорово! Этим и мотивируется JIT-компиляция, гибридная техника, которая совмещает в себе преимущества интерпретаторов и компиляторов. В двух словах – JIT старается использовать компиляцию, чтобы ускорить систему интерпретации.
Например, вот распространенный подход JIT:
В этом вся суть PyPy: использовать JIT в Питоне (в дополнении можно найти предыдущие попытки). Конечно, есть и другие цели: PyPy нацелен на кроссплатформенность, работу с небольшим количеством памяти и поддержку stackless (отказа от стека вызовов языка Си в пользу собственного стека). Но JIT это главное преимущество. В среднем на основе временных тестов, фактор ускорения составляет 6.27. Более подробные данные можно получить из схемы от PyPy Speed Center:
В PyPy сложно разобраться
У PyPy есть огромный потенциал, и в данный момент он хорошо совместим с CPython (так что на нем можно запускать Flask, Django, etc.).
Но с PyPy есть много путаницы. (оцените, к примеру, это бессмысленное предложение создать PyPyPy…). По моему мнению основная причина в том, что PyPy одновременно является:
Интерпретатором Питона, написанным на RPython (не Python (я обманул вас до этого)). RPython это подмножество Python со статичной типизацией. В Python, вести тщательные беседы о типах «в целом невозможно» почему это так сложно? рассмотрите следующее:
это корректный код на Python (спасибо Ademan‘у). Какой тип у x? Как мы можем обсуждать типы переменных, когда типы даже не форсируются?). В RPython мы жертвуем некоторой гибкостью, но взамен получаем возможность гораздо проще управлять памятью и много чего еще, что помогает при оптимизации.
Компилятором, который компилирует код на RPython в разные форматы и поддерживает JIT. Платформой по-умолчанию является Си, то есть компилятор RPython-в-Си, но в качестве целевой платформы также можно выбрать JVM и другие.
Для простоты описания, я буду называть их PyPy (1) и PyPy (2).
Зачем могут понадобиться эти две вещи, и почему – в одном наборе? Думайте об этом так: PyPy (1) это интерпретатор, написанный на RPython. То есть он берет пользовательский код на Питоне и компилирует его в байткод. Но чтобы сам интерпретатор (написанный на RPython) мог работать, он должен быть интерпретирован другой реализацией Питона, верно?
Итак, можно просто использовать CPython чтобы запускать интерпретатор. Но это будет не слишком быстро.
Вместо этого мы используем PyPy (2) (называемый RPython Toolchain) чтобы компилировать интерпретатор PyPy в код для другой платформы (например, C, JVM, или CLI) для запуска на конечной машине, с добавлением JIT. Это волшебно: PyPy динамически добавляет JIT к интерпретатору, генерируя собственный компилятор! (Опять же, это безумие: мы компилируем интерпретатор, добавляя другой отдельный, самостоятельный компилятор).
В конце концов результатом будет самостоятельный исполняемый файл, который интерпретирует исходный код на Питоне и использует оптимизацию JIT. То, что нужно! Понять сложновато, но, возможно, эта схема поможет:
Повторим: настоящая красота PyPy в том, что мы можем написать себе кучу разных интерпретаторов Питона на RPython не волнуясь о JIT (не считая пары деталей). После этого PyPy реализует для нас JIT, используя RPython Toolchain/PyPy (2).
На самом деле, если копнуть глубже в абстракцию, теоретически можно написать интерпретатор любого языка, направить его в PyPy и получить JIT для этого языка. Это возможно потому, что PyPy концентрируется на оптимизации самого интерпретатора, а не деталей языка, который тот интерпретирует.
Теоретически можно написать интерпретатор любого языка, направить его в PyPy и получить JIT для этого языка.
В качестве отступления я бы хотел заметить, что сам JIT совершенно восхитителен. Он использует технику под названием «отслеживание» (tracing), которая работает следующим образом:
Узнать больше можно из этой легкодоступной и очень интересной публикации.
Подытожим: мы используем PyPy-компилятор RPython-в-Си (или другую целевую платформу), чтобы скомпилировать реализованный на RPython интерпретататор PyPу.
Заключение
Почему все это так восхитительно? Почему стоит гнаться за этой безумной идеей? По-моему, Алекс Гейнор объяснил это очень хорошо в своем блоге: «[За PyPy будущее] потому что [он] более быстрый, более гибкий и является лучшей платформой для развития Питона».
Дополнение: другие названия, которые вы, возможно, слышали
Python 3000 (Py3k): альтернативное название Python 3.0, основной релиз Питона с обратной совместимостьюкоторый появился в 2008. году. Команда Py3k предсказала, что новой версии понадобится примерно пять лет чтобы полностью прижиться. И в то время, как большинство (внимание: надуманное утверждение) разработчиков на Питоне продолжают использовать Python 2.x, люди все больше задумываются о Py3k.
Numba: «специализированный just-in-time компилятор», который добавляет JIT в снабженный примечаниями код на Питоне. Проще говоря, вы даете ему подсказки, а он ускоряет некоторые части вашего кода. Numba является частью дистрибутива Anaconda набора пакетов для анализа и управления данными.
IPython: сильно отличается от всего, что мы обсудили. Вычислительная среда для Питона. Интерактивная, с поддержкой GUI-пакетов, браузеров и так далее.
Привязки к языкам
RubyPython: мост между виртуальными машинами Ruby и Python. Позволяет встраивать код на Питоне в код на Ruby. Вы обозначаете, где начинается и заканчивается Питон, а RubyPython обеспечивает передачу данных между виртуальными машинами.
PyObjc: языковое соединение между Python и Objective-C, которые ведет себя как мост между ними. На практике это означает, что вы можете использовать библиотеки Objective-C (включая все, что нужно для создания приложения под OS X) в коде на Питоне, и модули Питона в коде на Objective-C. Это удобно, потому что CPython написан на Си, который является подмножеством Objective-C.
PyQt: в то время как PyObjc позволяет связать Питон с компонентами OS X GUI, PyQt делает то же для фреймворка Qt. Это дает возможность создавать полноценные графические интерфейсы, обращаться к SQL базам данных и так далее. Еще один инструмент, нацеленный на перенос простоты Питона в другие фреймворки.
JavaScript фреймворки
pyjs (Pyjamas): фреймворк для создания веб и десктопных приложений на Питоне. Включает в себя компилятор Python-в-JavaScript, набор виджетов и некоторые другие инструменты.
Brython: виртуальная машина Python, написанная на Javascript. Позволяет запустить код на Py3k в веб-браузере.
Титульное фото: technopathic.deviantart.com
Хотите сообщить важную новость? Пишите в Телеграм-бот.
А также подписывайтесь на наш Телеграм-канал.