Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

Отчего существует так много Питонов?

Anna | 15.06.2014 | нет комментариев
Питон великолепен.

Изумительно, но это достаточно неоднозначное заявление. Что я имею ввиду под “Питоном”? Может, отвлеченный интерфейс Питона? Либо 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.

Новички нередко допускают, что Питон компилируемый из-за наличия .pyc-файлов. Это отчасти правильно: .pyc-файлы – это скомпилированный байткод, тот, что позднее интерпретируется. Так что если вы запускали ваш код на Питоне, и у вас есть .pyc-файл, то во 2-й раз он будет трудиться стремительней, потому что ему не необходимо будет снова компилироваться в байткод.

Альтернативные виртуальные машины: Jython, IronPython и другие

Как я говорил выше, у Питона существует несколько реализаций. Вновь же, как говори-лось выше, самой знаменитой является CPython. Эта версия Питона написана на C и подход JIT:

  1. Определить байткод, тот, что запускается Зачастую.
  2. Скомпилировать его в нативный машинный код.
  3. Закэшировать итог.
  4. Неизменно когда нужно запустить тот же самый байткод, применять теснее скомпилированный машинный код и пожинать плоды (в частности, приход скорости).

В этом каждая суть 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 в области JIT. Давным-давно помечен как “неподдерживаемый и мертвый”. Основной разработчик Psyco Армин Риго теперь работает над PyPy.

Привязки к языкам
  • 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 в веб-браузере.
 Источник: programmingmaster.ru
Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB