со-основатель Hexlet.io
174,7
рейтинг
21 января 2014 в 12:56

Разработка → Почему существует так много Питонов? перевод

Питон изумителен.

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


Альтернативные виртуальные машины: 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]


IronPython это другая популярная реализация Питона, написанная полностью на C# и предназначенная для .NET. В частности, она запускается на виртуальной машине .NET, если ее можно так назвать, на Common Language Runtime (CLR), от Майкрософт, сравнимым с JVM.

Можно сказать, что Jython: Java :: IronPython: C#. Они работают на соответствующих виртуальных машинах, есть возможность импортировать классы C# в код IronPython и классы Java в код Jython, и так далее.

Вполне реально выжить, не прикасаясь к ни к чему, кроме CPython. Но, переходя на другие имплементации, вы получаете преимущество, в основном из-за используемого стека технологий. Используете много языков, основанных на JVM? Jython может вам подойти. Все на .NET? Возможно, стоит попробовать IronPython (и, возможно, вы уже сделали).



Кстати, хоть это и не станет причиной для перехода на другую имплементацию, стоит упомянуть, что имплементации эти на самом деле отличаются поведением. Это касается не только способов интерпретации кода на Питоне. Однако эти отличия, как правило, не-значительны, они исчезают и появляются со временем из-за активной разработки. К примеру, 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:

  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 для этого языка. Это возможно потому, что PyPy концентрируется на оптимизации самого интерпретатора, а не деталей языка, который тот интерпретирует.

В качестве отступления я бы хотел заметить, что сам JIT совершенно восхитителен. Он использует технику под названием “отслеживание” (tracing), которая работает следующим образом:

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


Узнать больше можно из этой легкодоступной и очень интересной публикации.

Подытожим: мы используем PyPy-компилятор RPython-в-Си (или другую целевую плат-форму), чтобы скомпилировать реализованный на RPython интерпретататор PyPу.

Заключение



Почему все это так восхитительно? Почему стоит гнаться за этой безумной идеей? По-моему, Алекс Гейнор объяснил это очень хорошо в своем блоге: “[За PyPy будущее] потому что [он] более быстрый, более гибкий и является лучшей платформой для развития Питона”.

Вкратце:

  • Он быстрый – потому что компилирует исходный код в нативный код (используя JIT).
  • Он гибкий – потому что добавляет JIT в интерпретатор без особых усилий.
  • Он гибкий (опять) – потому что вы можете писать интерпретаторы в RPython, что впоследствии упрощает расширение по сравнению с тем же Си (на самом деле упрощает настолько, что даже есть инструкция по написанию собственных интерпретаторов).


Дополнение: другие названия, которые вы, возможно, слышали



Python 3000 (Py3k): альтернативное название Python 3.0, основной релиз Питона с обратной совместимостью, который появился в 2008. году. Команда Py3k предсказала, что новой версии понадобится примерно пять лет чтобы полностью прижиться. И в то время, как большинство (внимание: надуманное утверждение) разработчиков на Питоне продолжают использовать Python 2.x, люди все больше задумываются о Py3k.

Cython: надмножество Python, включающее возможность вызывать функции Си.
  • Задача: позволить писать расширения Си для программ на Питоне.
  • Также позволяет добавлять статическую типизацию в существующий код на Питоне, что после повторной компиляции может помочь достичь похожей на Си производительности.
  • Напоминает PyPy, но это не то же самое. В случае с Cython вы форсируете типизацию в пользовательском коде перед подачей компилятору. В PyPy вы пишете старый добрый Python, а компилятор отвечает за любую оптимизацию.


Numba: “специализированный just-in-time компилятор”, который добавляет JIT в снабженный примечаниями код на Питоне. Проще говоря, вы даете ему подсказки, а он ускоряет некоторые части вашего кода. Numba является частью дистрибутива Anaconda набора пакетов для анализа и управления данными.

IPython: сильно отличается от всего, что мы обсудили. Вычислительная среда для Питона. Интерактивная, с поддержкой GUI-пакетов, браузеров и так далее.

Psyco: модуль расширения Питона, одна из первых попыток Питона в области 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 в веб-браузере.
Перевод: Charles Marsh
Рахим Давлеткалиев @freetonik
карма
506,5
рейтинг 174,7
со-основатель Hexlet.io
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (70)

  • +5
    Вы молодец, спасибо за перевод. Сам начал переводить эту статью и как-то отвлекся)
    • +1
      Спасибо!
  • +5
    Информация очень полезная, но читается достаточно сложно из-за неестественных оборотов и предложений. Но все равно спасибо за труд.
  • +4
    Классные картинки!
  • +5
    Пример python 3 — это яркий пример того, что бывает с проектами, которые забивают на обратную совместимость.
    • +26
      я бы поправил — «забивают на обратную совместимость, не привнося значительных преимуществ».
    • 0
      >проектами, которые забивают на обратную совместимость
      Да ладно вам — посмотрите на пхп, да и в других языках при переходе между минорными версиями возникают проблемы, а мы просто изнежились и обленились.
      • 0
        Минорные проблемы — да. А вот дистанцироваться и сказать «а теперь все дружными рядами в светлое будущее, где неюникодных строк не бывает, переписали всё» — это нет. Не будет.
  • +5
    отличная статья, сразу захотелось потрогать PyPy )
    • +1
      PyPy — замечательная вещица. Математические вычисления на нём идут на порядок быстрее. Есть numpypy — порт библиотеки numpy. Из минусов
      • Отсутствие ABI совместимости с CPython. То есть нельзя использовать Python расширения написанные на C, такие как PyQt/PySide, PIL, subvertpy, др. Есть конечно костыли, в виде CFFI.
      • Нет поддержки Python 3.x. Разработка PyPy 3k ещё в статусе альфы. Можно пожертвовать.
      • Нет сборки под Windows 64 bit.

      Зато разработчики PyPy могут экспериментировать с языком. Например есть ветка, в которой добавляют Software Transactional Memory. Можно почитать об этом в Design Notes или в блоге. Как обычно, разработчики не возражают против добровольных пожертвований на STM.
      • +1
        А есть тесты numpy vs numpypy? Что-то мне кажется оно не особо быстрее будет, ведь ядро numpy на фортране.
        • 0
          С чего бы оно вообще было быстрее? Скорее это какой-то proof-of-concept, что оно не катастрофически медленнее.
      • +1
        На практике математические вычисления все равно в numpy или Cython-расширениях делают; pypy для этого подходит хуже, т.к. работает медленнее и «базовых» библиотек нет — numpy, scipy и т.д. PyPy штука крутая, но для математики (пока?) бесполезная.
  • +2
    Я бы еще добавил проект nuitka.
  • +2
    Оффтоп. А посоветуйте книжку по PyQt хорошую, пожалуйста.
    • +8
      Любая книжка по Qt должна помочь. Там нет ничего такого особенного. Просто Qt-API и язык Python. Если знаете Qt, то автоматически знаете большую часть PyQt.

      Но книжка по PyQt есть: «Rapid GUI Programming with Python and Qt».
      • +1
        Спасибо.
      • +4
        Прохоренок Н. А. «PyQt4. Создание оконных приложений на Python 3». На русском.
        • 0
          причем примеры кода из книги отлично работают и в python2 (с очень незначительным переписыванием).
  • +3
    Тема с Brython заинтересовала. Кто-нибудь юзал это в реальных проектах? Как дела у него с другими либами? Как с производительностью?
    • +5
      Производительность как нетрудно догадаться слабая: pyppet.blogspot.ru/2013/11/brython-vs-pythonjs.html
    • +5
      согласен, питон в браузере привлекает намного больше, чем джаваскрипт на сервере)
      • 0
        class GiveMeJS(object):    
            def __init__(self, *args, **kwargs):
                self.args = args
        
                for k, v in kwargs.items():
                    setattr(self, k, v)
        
            def __call__(self, *args, **kwargs):
                for k, v in self.__dict__.items():            
                    print ('%s: %s' % (k, v))
        
        
        o = GiveMeJS(*[1, 2, 3], **{'test': '123', '1': 12})
        o()
        


        PythonJS пока не умеет импортить. Код выше прожевал только Brython, PythonJS не захотел понимать `.items()`. Пока далековато до питона на клиентсайде. Но в целом занятная тема.

        P.S. 1 2
    • +1
      Производительность никакая. Проход по циклу из 1000 элементов — около секунды. Да и он многого не умеет. Длинную арифметику, например. Нет стандартной библиотеки. Т.е. эта игрушка вряд ли способна помочь Python'у «подвинуть» Javascript на клиентах. Но как эксперимент, безусловно, интересна.
  • +3
    Так и не понял :( JIT компиляция есть в CLR и в большинстве JVM. Чем тогда архитектурно PyPy отличается от IronPython например?
    • +2
      PyPy изначально заточен под динамическую типизацию, например.
  • +8
    Замечание: это не совсем “компиляция” в традиционном смысле. Обычно, мы считаем, что “компиляция” это конвертация из высокоуровневого языка в машинный код. Тем не менее – в некотором роде это “компиляция”.


    А я обычно считал, что все это называется «трансляция» (в машинный код, в байт-код). А компиляция — это обычно сборка исполняемого файла, обычно из того, что получается в результате трансляции. А называют это компиляцией по незнанию, потому что кнопочка в IDE так называется (основное ее действие — компиляция, а трансляция производится частично по мере необходимости).
    • +1
      В официальной документации, кстати, встречаются оба термина. Вот например такая фраза: «The compiler package is a Python source to bytecode translator written in Python». Интересно было бы знать, обоснованно ли использование термина «компиляция», или же это просто всеобщая привычка.
    • +4
      Сборка исполняемого файла — это линковка (linking, «редактирование связей»). Трансляция — перевод программы на любом языкы в программу на любом другом языке. Компиляция — подмножество трансляции, когда перевод осуществляется с высокоуровневого языка в низкоуровневый, чаще всего машинный.
      • +1
        Ок. А как на счет того, что слово «компиляция» — английское, а «сборка» — русское, и «compile» как раз и переводится как «собирать» или «составлять»? Возможно именно это меня и сбило с толку, я всегда думал что это одно и тоже, просто на разных языках.
        • +3
          Хм, ну я бы не говорил так однозначно, что «компиляция» — это английское слово :) Оно есть ещё у Даля.

          Сборка (в отношении программ), вообще говоря, будет «build». Обычно сборка включает в себя, в частности, компиляцию и линковку (кстати, вспомнил ещё один синоним linking — компоновка).
          • 0
            У Даля написано «лат.», что как бы намекает на происхождение, да?
            И ведь компиляция программ — это именно перевод с английского «to compile».
            • 0
              У Даля написано «лат.», что как бы намекает на происхождение, да?

              Да, именно так. И ещё я имел в виду что это слово появилось в русском языке задолго до компьютерной эры, но это так, просто к слову)
          • 0
            Похоже, все почти так и есть. Я догадался посмотреть в Википедию :) вот что там пишут:
            The name «compiler» is primarily used for programs that translate source code from a high-level programming language to a lower level language (e.g., assembly language or machine code).

            A program that translates between high-level languages is usually called a language translator, source to source translator, or language converter.

            А вот что еще интересного там говорится:
            A compiler is likely to perform many or all of the following operations: lexical analysis, preprocessing, parsing, semantic analysis (Syntax-directed translation), code generation, and code optimization.

            Видимо, именно поэтому и называется компиляция: трансляция — это всего лишь часть большой работы компилятора. Компиляция — это сложный процесс, включающий трансляцию.

            Спасибо за помощь в этом запутанном деле :)
      • 0
        Проблема терминологии действительно есть. Компиляцией можно называть то самое подмножество трансляции. С другой стороны, раздельная компиляция — тоже устоявшийся термин, но он подразумевает отделение трансляции от компоновки, то есть и компиляция как совокупность трансляции и компоновки — тоже верно.
        • 0
          Почему можно? Вы можете показать, от куда ноги растут? Я просто пытаюсь понять: это общая ошибка ставшая нормой, или же в этом есть какой-то смысл?
          • 0
            все, вроде выяснил, смотрите выше :)
            • +1
              Ну вот вы выяснили из википедии, что трансляция — часть работы компилятора. А достаточно открыть википедию русскую, где говорится, что «Компиляция — трансляция программы, составленной на исходном языке высокого уровня, в эквивалентную программу на низкоуровневом языке». Впрочем, это написано и у вас, из английской версии.

              Вот и получается, что даже в пределах одной статьи компиляцию называют и трансляцией, и большим набором работ, включающим в себя трансляцию.

              Проблема, думаю, в самих процессах, происходящих при компиляции. В процессе компиляции может же происходить промежуточная трансляция, допустим, в ассемблер. Вот и получается, что внутри одного транслятора работает другой. И для отсутствия путаницы компилятор, выходит, лучше пореже называть транслятором.
              • 0
                Ну да, и я о том же
  • +4
    Можно ещё упомянуть попытку создания компилятора для Python сразу в нативный код или через промежуточный C/C++ код.
    Например, Shedskin — экспериментальный компилятор, который может транслировать статически типизированный код на Python (2.4-2.6) в оптимизированный код на C++.
    Для набора из 75 простейших программ (более 25 тыс.строк sloccount)), измерения демонстрируют прирост скорости в 2-200 раз по сравнению с CPython.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +4
      Да ну, я вот тоже говорю «питон». Это жаргон, всем понятно, что правильно «пайтон». Это как «писать на сях», или «пэхапэ» :)
      • НЛО прилетело и опубликовало эту надпись здесь
        • +3
          Обычно пишут Джава или Ява. И одни все время желают смерти другим.

          Что касается менее оффтопного в данном случае языка, то обычно говорю Пайтон, и снова оказываюсь явно не в большинстве.
          • НЛО прилетело и опубликовало эту надпись здесь
            • 0
              Не «коверкать», а адаптировать к русскому языку. По сходным причинам сейчас чаще можно увидеть «в интернете», нежели «в сети Internet».
              • НЛО прилетело и опубликовало эту надпись здесь
            • +7
              В языке (не только русском, любом) правильно говорить так, как принято, как говорят другие люди. «Норма» это и означает. А заимстванные слова часто теряют свое произношение. Мы же не говорим «Ландан» и «Чёчил», а говорим «Лондон» и «Черчилль». В случае с питоном все усугубляется тем, что название вполне можно перевести, нужное слово в русском языке есть, оно короткое и удобно произносится. Можно спорить о переводе (Монти Пайтон или питон?), но это уже занудство — даже на логотипе змея есть, так тоже можно переводить. Мне лично не кажется, что «питон» — это жаргон, использование слова «питон» вполне оправдано. Если кому-то нравится «пайтон» — тоже никаких проблем, этот вариант тоже вполне оправдан. Проблемы начинаются, когда люди начинают думать, что их вариант — единственно правильный :)
    • +2
      Да ладно вам. Меня вот каждый раз при виде PyPy мучает непреодолимое желание прочитать это как ПуПу
      • 0
        Хм, я всегда так читаю.
      • 0
        Это еще ладно, конференции проходят — пуконы.
      • 0
        Мне вообще всё время как «пипи» хочется прочитать (типа сокращение от «питон»)
  • +2
    PyPy никогда не станет будущим (по крайней мере еще с десяток лет) питона по двум причинам, они еще косвенно были озвучены GvR (см. ссылку ниже):
    — потеря совместимости с расширениями, написанными на Си (которые используют CPython API). Проблема думаю решается (перекомпиляцией и/или предоставлением совместимого API), но пока она существует.
    — JIT имеет безумно долгое время запуска. Это обсуждалось на форумах PyPy, но они непреклонны, и сказали, что просто надо использовать долгоиграющие процессы.

    Более детально это обсуждалось на Stack Overflow: stackoverflow.com/questions/12867263/why-wasnt-pypy-included-in-standard-python

    К сожалению, скорость запуска еще очень важна, особенно для встраиваемых платформ. Несмотря на то, что по ссылке выше сказали, что скорость запуска соразмерима, это не правда. Я проводил собственные эксперименты с нашим оборудованием для бюджетного сектора (соответственно самые дешевые модели с самыми медленными процессорами ARM и без SSD), скорость запуска скрипта CPython — около 300-500 мс, PyPy — 2+ сек. Да, поддержка ARM в PyPy не особо, сами процессоры ARM не такие уж шустрые, плюс как я уже отметил, можно использовать демоны, но факт остается фактом. Опять-таки, несмотря на заявления разработчиков PyPy, он потребляет больше памяти (по-крайней мере, для специфических задач, как мелкие скрипты или CGI).

    Сейчас CPython — более оптимизированное и компромисионное решение. Начиная с 2.7 они правда сделали громадную глупость, из-за которой мы пока тоже не можем на него перейти, но это не имеет отношения к PyPy.
    • 0
      А можно детальней о глупости?

      И интересно, какие именно встраиваемые аппликации пишете на Python.
      • +1
        2.7+ парсит pyconfig.h при запуске, что замедляет запуск и требует наличия этого файла (а он весит около 100кбайт) на запускающей платформе (http://bugs.python.org/issue9878). В 3.3+ они это пофиксили, но переходить на тройку мы вообще пока не можем, т.к. она требует обновленное ядро Linux и сопутствующих библиотек.

        Я в команде разработки веб-интерфейса к встраиваемым системам. Использовать python не самая удачная идея, но это то, с чем приходится работать. Очень много проблем с производительностью и потреблением памяти. Я надеялся на PyPy, когда делал исследования в области улучшения производительности, но он себя показал не с лучшей стороны. Обходные пути есть, и использовать PyPy все-таки можно, но это только в далекой перспективе. К сожалению, когда это перспектива придет, уже не надо будет заботиться о производительности, т.к. все старые модели больше не будут поддерживаться.
        • 0
          А что бы Вы выбрали вместо Python в вашем случае?
          • +1
            Думаю, Lua. Мне очень не нравятся языки программирования со слабой типизацией (навскидку Lua, JavaScript, Basic, PHP), но просто особо нет выбора. Собственно, Python и был выбран изначально, потому что это полноценный язык программирования с большой библиотекой, а не набор костылей как PHP или «найди-ошибку-в-ворохе-кода-потому-что-я-неявно-привел-число-в-строку» JS/Lua. Но в конечном счете именно производительность оказалась решаюшим фактором, поэтому сейчас мы делаем минимальную работу на серверной стороне, и больше перекладываем на браузер (отдаем JSON, а всем рендерингом занимается JS).
  • +3
    Я не понимаю, а почему было принципиально писать JIT именно на питоне? Почему нельзя было встроить его в тот же CPython и получить еще большую скорость? Неужели написание JIT-компилятора на питоне на порядки проще, чем на Си?
    • +1
      Это в первую очередь исследовательский проект был. И на питоне было проще писать
  • 0
    У IronPython есть еще одна интересная особенность. Поскольку он использует DLR, который по сути является стандартным способом реализации динамически типизированных языков на CLR, то он совместим с другими языками, тоже использующими DLR. Т.е., например, с IronRuby — можно создать объект в руби, передать его в питон, и подергать на нем методы.
  • +6
    Как сделать схемы из топика «на лету»? Или ручками рисовалось?
    • 0
      Присоединяюсь к вопросу.
  • +1
    CPython упрощает написание C-расширений для кода на Питоне потому что в конце он запускается интерпретатором Cи

    После «он запускается интерпретатором Cи» кажется что в конце чего-то, именно CPython будет запускаться на некоем интерпретаторе Cи. Есть маленькое подозрение, что тут где-то ошибка. Попробуем разобраться.

    Версия:
    CPython упрощает написание C-расширений для кода на Питоне потому что в конце C-расширение компилируется C-компилятором.
    С си-расширениями получилось немного излишне хотя и все логично, но мог ли автор так ошибиться…

    Возможно имеется ввиду:
    В конце компиляции самого CPython, и то что CPython написан на си (что упоминалось ранее) — упрощает написание C-расширений для кода на Питоне.
    Но все-таки это «интерпретатором Cи»…

    Версия:
    CPython упрощает написание C-расширений для кода на Питоне потому что в конце этот код запускается интерпретатором CPython
    И тогда мы можем предположить что основная мысль:
    Если код на Питоне запускается интерпретатором CPython, то это упрощает написание C-расширений

    Ваши версии?
    • 0
      а почему не посмотреть сразу в оригинал?
      > CPython makes it very easy to write C-extensions for your Python code because in the end it is executed by a C interpreter.
      я бы перевел «CPython упрощает написание Си-расширений для кода на питоне потому что в итоге [вообще весь] код исполняется интерпретатором, написанным на Си»
      • 0
        А я забавы ради. Оригинальная статья интересна набором ссылок. Но есть технические ляпы и много воды в виде «прозрений» автора.
        И не вижу я в «executed by a C interpreter» слова «исполняется интерпретатором, написанным на Си».
  • +1
    Как мы можем обсуждать типы переменных, когда типы даже не форсируются?

    В случае с Cython вы форсируете типизацию в пользовательском коде перед подачей компилятору.

    «Сегодня мне пришлось явно указать тип форсировать Днепр тип»
  • +1
    Господа питонисты, а так ли часто эта хвалёная кроссплатформенность питона на уровне байт-кода используется? То есть транслируем *.py файл с исходником в *.pyc или *.pyo и уже его переносим между машинами с разными осями и/или архитектурами. Правда, что люди так делают? Если да, то в каких проектах и условиях?

    Мне правда интересно.
    • 0
      zip-модули с байт-кодом отлично переносятся между разными машинами/осями, я писал об этом недавно.
      Самый известный вариант применения — это видимо setuptools/eggs
  • +1
    А не подскажете, что можно почитать про Stackless Python? Он вообще жив ещё?
  • 0
    "… у вас есть .pyc-файл, то во второй раз он будет работать быстрее..."
    Это неправда, скрипты с pyc будут запускаться быстрее, но работать будут точно так же

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.