Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 74
Вы молодец, спасибо за перевод. Сам начал переводить эту статью и как-то отвлекся)
Информация очень полезная, но читается достаточно сложно из-за неестественных оборотов и предложений. Но все равно спасибо за труд.
Классные картинки!
Пример python 3 — это яркий пример того, что бывает с проектами, которые забивают на обратную совместимость.
я бы поправил — «забивают на обратную совместимость, не привнося значительных преимуществ».
>проектами, которые забивают на обратную совместимость
Да ладно вам — посмотрите на пхп, да и в других языках при переходе между минорными версиями возникают проблемы, а мы просто изнежились и обленились.
Да ладно вам — посмотрите на пхп, да и в других языках при переходе между минорными версиями возникают проблемы, а мы просто изнежились и обленились.
отличная статья, сразу захотелось потрогать PyPy )
PyPy — замечательная вещица. Математические вычисления на нём идут на порядок быстрее. Есть
Зато разработчики PyPy могут экспериментировать с языком. Например есть ветка, в которой добавляют Software Transactional Memory. Можно почитать об этом в Design Notes или в блоге. Как обычно, разработчики не возражают против добровольных пожертвований на STM.
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.
А есть тесты numpy vs numpypy? Что-то мне кажется оно не особо быстрее будет, ведь ядро numpy на фортране.
На практике математические вычисления все равно в numpy или Cython-расширениях делают; pypy для этого подходит хуже, т.к. работает медленнее и «базовых» библиотек нет — numpy, scipy и т.д. PyPy штука крутая, но для математики (пока?) бесполезная.
Я бы еще добавил проект nuitka.
Оффтоп. А посоветуйте книжку по PyQt хорошую, пожалуйста.
Тема с Brython заинтересовала. Кто-нибудь юзал это в реальных проектах? Как дела у него с другими либами? Как с производительностью?
Производительность как нетрудно догадаться слабая: pyppet.blogspot.ru/2013/11/brython-vs-pythonjs.html
согласен, питон в браузере привлекает намного больше, чем джаваскрипт на сервере)
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
Производительность никакая. Проход по циклу из 1000 элементов — около секунды. Да и он многого не умеет. Длинную арифметику, например. Нет стандартной библиотеки. Т.е. эта игрушка вряд ли способна помочь Python'у «подвинуть» Javascript на клиентах. Но как эксперимент, безусловно, интересна.
Так и не понял :( JIT компиляция есть в CLR и в большинстве JVM. Чем тогда архитектурно PyPy отличается от IronPython например?
PyPy изначально заточен под динамическую типизацию, например.
Сборка исполняемого файла — это линковка (linking, «редактирование связей»). Трансляция — перевод программы на любом языкы в программу на любом другом языке. Компиляция — подмножество трансляции, когда перевод осуществляется с высокоуровневого языка в низкоуровневый, чаще всего машинный.
Хм, ну я бы не говорил так однозначно, что «компиляция» — это английское слово :) Оно есть ещё у Даля.
Сборка (в отношении программ), вообще говоря, будет «build». Обычно сборка включает в себя, в частности, компиляцию и линковку (кстати, вспомнил ещё один синоним linking — компоновка).
Сборка (в отношении программ), вообще говоря, будет «build». Обычно сборка включает в себя, в частности, компиляцию и линковку (кстати, вспомнил ещё один синоним linking — компоновка).
Проблема терминологии действительно есть. Компиляцией можно называть то самое подмножество трансляции. С другой стороны, раздельная компиляция — тоже устоявшийся термин, но он подразумевает отделение трансляции от компоновки, то есть и компиляция как совокупность трансляции и компоновки — тоже верно.
Ну вот вы выяснили из википедии, что трансляция — часть работы компилятора. А достаточно открыть википедию русскую, где говорится, что «Компиляция — трансляция программы, составленной на исходном языке высокого уровня, в эквивалентную программу на низкоуровневом языке». Впрочем, это написано и у вас, из английской версии.
Вот и получается, что даже в пределах одной статьи компиляцию называют и трансляцией, и большим набором работ, включающим в себя трансляцию.
Проблема, думаю, в самих процессах, происходящих при компиляции. В процессе компиляции может же происходить промежуточная трансляция, допустим, в ассемблер. Вот и получается, что внутри одного транслятора работает другой. И для отсутствия путаницы компилятор, выходит, лучше пореже называть транслятором.
Вот и получается, что даже в пределах одной статьи компиляцию называют и трансляцией, и большим набором работ, включающим в себя трансляцию.
Проблема, думаю, в самих процессах, происходящих при компиляции. В процессе компиляции может же происходить промежуточная трансляция, допустим, в ассемблер. Вот и получается, что внутри одного транслятора работает другой. И для отсутствия путаницы компилятор, выходит, лучше пореже называть транслятором.
Можно ещё упомянуть попытку создания компилятора для Python сразу в нативный код или через промежуточный C/C++ код.
Например, Shedskin — экспериментальный компилятор, который может транслировать статически типизированный код на Python (2.4-2.6) в оптимизированный код на C++.
Для набора из 75 простейших программ (более 25 тыс.строк sloccount)), измерения демонстрируют прирост скорости в 2-200 раз по сравнению с CPython.
Например, Shedskin — экспериментальный компилятор, который может транслировать статически типизированный код на Python (2.4-2.6) в оптимизированный код на C++.
Для набора из 75 простейших программ (более 25 тыс.строк sloccount)), измерения демонстрируют прирост скорости в 2-200 раз по сравнению с CPython.
Обычно пишут Джава или Ява. И одни все время желают смерти другим.
Что касается менее оффтопного в данном случае языка, то обычно говорю Пайтон, и снова оказываюсь явно не в большинстве.
Что касается менее оффтопного в данном случае языка, то обычно говорю Пайтон, и снова оказываюсь явно не в большинстве.
Не «коверкать», а адаптировать к русскому языку. По сходным причинам сейчас чаще можно увидеть «в интернете», нежели «в сети Internet».
В языке (не только русском, любом) правильно говорить так, как принято, как говорят другие люди. «Норма» это и означает. А заимстванные слова часто теряют свое произношение. Мы же не говорим «Ландан» и «Чёчил», а говорим «Лондон» и «Черчилль». В случае с питоном все усугубляется тем, что название вполне можно перевести, нужное слово в русском языке есть, оно короткое и удобно произносится. Можно спорить о переводе (Монти Пайтон или питон?), но это уже занудство — даже на логотипе змея есть, так тоже можно переводить. Мне лично не кажется, что «питон» — это жаргон, использование слова «питон» вполне оправдано. Если кому-то нравится «пайтон» — тоже никаких проблем, этот вариант тоже вполне оправдан. Проблемы начинаются, когда люди начинают думать, что их вариант — единственно правильный :)
Да ладно вам. Меня вот каждый раз при виде PyPy мучает непреодолимое желание прочитать это как ПуПу
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.
— потеря совместимости с расширениями, написанными на Си (которые используют 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.
А можно детальней о глупости?
И интересно, какие именно встраиваемые аппликации пишете на Python.
И интересно, какие именно встраиваемые аппликации пишете на Python.
2.7+ парсит pyconfig.h при запуске, что замедляет запуск и требует наличия этого файла (а он весит около 100кбайт) на запускающей платформе (http://bugs.python.org/issue9878). В 3.3+ они это пофиксили, но переходить на тройку мы вообще пока не можем, т.к. она требует обновленное ядро Linux и сопутствующих библиотек.
Я в команде разработки веб-интерфейса к встраиваемым системам. Использовать python не самая удачная идея, но это то, с чем приходится работать. Очень много проблем с производительностью и потреблением памяти. Я надеялся на PyPy, когда делал исследования в области улучшения производительности, но он себя показал не с лучшей стороны. Обходные пути есть, и использовать PyPy все-таки можно, но это только в далекой перспективе. К сожалению, когда это перспектива придет, уже не надо будет заботиться о производительности, т.к. все старые модели больше не будут поддерживаться.
Я в команде разработки веб-интерфейса к встраиваемым системам. Использовать python не самая удачная идея, но это то, с чем приходится работать. Очень много проблем с производительностью и потреблением памяти. Я надеялся на PyPy, когда делал исследования в области улучшения производительности, но он себя показал не с лучшей стороны. Обходные пути есть, и использовать PyPy все-таки можно, но это только в далекой перспективе. К сожалению, когда это перспектива придет, уже не надо будет заботиться о производительности, т.к. все старые модели больше не будут поддерживаться.
Думаю, Lua. Мне очень не нравятся языки программирования со слабой типизацией (навскидку Lua, JavaScript, Basic, PHP), но просто особо нет выбора. Собственно, Python и был выбран изначально, потому что это полноценный язык программирования с большой библиотекой, а не набор костылей как PHP или «найди-ошибку-в-ворохе-кода-потому-что-я-неявно-привел-число-в-строку» JS/Lua. Но в конечном счете именно производительность оказалась решаюшим фактором, поэтому сейчас мы делаем минимальную работу на серверной стороне, и больше перекладываем на браузер (отдаем JSON, а всем рендерингом занимается JS).
Я не понимаю, а почему было принципиально писать JIT именно на питоне? Почему нельзя было встроить его в тот же CPython и получить еще большую скорость? Неужели написание JIT-компилятора на питоне на порядки проще, чем на Си?
У IronPython есть еще одна интересная особенность. Поскольку он использует DLR, который по сути является стандартным способом реализации динамически типизированных языков на CLR, то он совместим с другими языками, тоже использующими DLR. Т.е., например, с IronRuby — можно создать объект в руби, передать его в питон, и подергать на нем методы.
CPython упрощает написание C-расширений для кода на Питоне потому что в конце он запускается интерпретатором Cи
После «он запускается интерпретатором Cи» кажется что в конце чего-то, именно CPython будет запускаться на некоем интерпретаторе Cи. Есть маленькое подозрение, что тут где-то ошибка. Попробуем разобраться.
Версия:
CPython упрощает написание C-расширений для кода на Питоне потому что в конце C-расширение компилируется C-компилятором.
С си-расширениями получилось немного излишне хотя и все логично, но мог ли автор так ошибиться…
Возможно имеется ввиду:
В конце компиляции самого CPython, и то что CPython написан на си (что упоминалось ранее) — упрощает написание C-расширений для кода на Питоне.
Но все-таки это «интерпретатором Cи»…
Версия:
CPython упрощает написание C-расширений для кода на Питоне потому что в конце этот код запускается интерпретатором CPython
И тогда мы можем предположить что основная мысль:
Если код на Питоне запускается интерпретатором CPython, то это упрощает написание C-расширений
Ваши версии?
а почему не посмотреть сразу в оригинал?
> 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 упрощает написание Си-расширений для кода на питоне потому что в итоге [вообще весь] код исполняется интерпретатором, написанным на Си»
> 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 упрощает написание Си-расширений для кода на питоне потому что в итоге [вообще весь] код исполняется интерпретатором, написанным на Си»
Как мы можем обсуждать типы переменных, когда типы даже не форсируются?
…
В случае с Cython вы форсируете типизацию в пользовательском коде перед подачей компилятору.
«Сегодня мне пришлось
Господа питонисты, а так ли часто эта хвалёная кроссплатформенность питона на уровне байт-кода используется? То есть транслируем *.py файл с исходником в *.pyc или *.pyo и уже его переносим между машинами с разными осями и/или архитектурами. Правда, что люди так делают? Если да, то в каких проектах и условиях?
Мне правда интересно.
Мне правда интересно.
zip-модули с байт-кодом отлично переносятся между разными машинами/осями, я писал об этом недавно.
Самый известный вариант применения — это видимо setuptools/eggs
Самый известный вариант применения — это видимо setuptools/eggs
А не подскажете, что можно почитать про Stackless Python? Он вообще жив ещё?
"… у вас есть .pyc-файл, то во второй раз он будет работать быстрее..."
Это неправда, скрипты с pyc будут запускаться быстрее, но работать будут точно так же
Это неправда, скрипты с pyc будут запускаться быстрее, но работать будут точно так же
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему существует так много Питонов?