Доступен выпуск проекта Nuitka 0.6.17, развивающего компилятор для трансляции скриптов на языке Python в представление на языке C++, которое затем можно скомпилировать в исполняемый файл, использующий libpython для обеспечения максимальной совместимости с CPython (используются штатные средства CPython для управления объектами). Обеспечена полная совместимость с актуальными выпусками Python 2.6, 2.7, 3.3 - 3.9. По сравнению с CPython скомпилированные скрипты демонстрируют в тестах pystone повышение производительности на 335%. Код проекта распространяется под лицензией Apache...Подробнее: https://www.opennet.me/opennews/art.shtml?num=56152
Самая удобная штука чтобы поставлять свою питоновскую программу в бинарном виде.
но зачем, если есть Julia?....
У этого языка противное название.
У питона с нулткой?.... Или у прекрасных женщин с именем Юлия?
Так сразу видно -- жульё, если конечно не думать одним прекрасным местом.
Надо иметь русские мозги чтобы слово Julia - Юлия прочитать как Жульё.
Вообще-то слово из Европы пришло...
На испанском - Хулия
Страшно подумать, что может вообразить обычный русскоговорящий человек, услышав это имя впервые. Ужас!
Осталось только понять, какое всё это имеет отношение к программированию?
Как скомпилируете в бинарник на ней что нибудь, то обязательно похвалитесь здесь пожалуйста!
А в чём, собственно, проблемы? Размер? Для серверных приложений это не проблема.
> А в чём, собственно, проблемы?В том, что Юлия, не компилится в бинарник своими core средствами.
Если вы знаете как сделать ELF бинарник без плясок с бубном (и без PackageCompiler модуля, который откровенно признаётся, что Julia "just-^BARELY^-ahead-of-time" compiled language, и далеко не всегда работающий как relocatable "app"), то буду признателен если поделитесь> Размер? Для серверных приложений это не проблема.
Если платить не из своего кармана, то оно конечно, - у амазона много ресурсов
PackageCompiler делает срез оперативки по коду/памяти. Собственно, какая вам разница из чего состоит бинарник?ELF-бинарник сделать можно, но там вопрос с библиотеками. Если есть куча сторонних зависимостей, особенно с питоном, будет куча сторонних динамических библиотек и всего, что им нужно. То есть, собрать всё в один файл, в общем случае, невозможно. Если зависимостей нет, то да, PackageCompiler с шаблоном на С, где будет код загрузки прописан, соберёт единый исполняемый файл.
> Если платить не из своего кармана, то оно конечно, - у амазона много ресурсов
Диски стоят дёшево. А размер этого бинарника не будет больше, чем то, что потребуется в оперативке, срезом с которой оно создано (только по глобальным переменным). Оно в любом случае потребуется для работы программы, хоть при маленьком бинарнике, хоть при большом сразу.
> PackageCompiler делает срез оперативки по коду/памяти.Дамп что ли? Это даже при снятии конверта (защиты) считается халтурой. Ещё со времён Спектрума и MagicButton.
сейчас даже "программист на питоне" халтурщиком не считается. А уж дамп с оперативки снять - вообще не проблема. Ну естественно, не чистый дамп. Трансляцию адресов необходимо обеспечить, чтобы потом загружаться правильно.
> PackageCompiler делает срез оперативки по коду/памяти.
> Собственно, какая вам разница из чего состоит бинарник?Есть языки, которые говорят что они "compiled ahead of time", такие каk программы на С, С++, Го...
а есть языки, которые говорят что они компилируемые, но переводят потом стрелки на зависимости что - не могут.Язык либо может быть комилирующим, всегда, либо нет, без оговорок на "если", поэтому если Вы говорите, "а зачем сабжект когда, есть Юля?", то сделайте выводы сами, - слишком много "если", даже без сторонних зависимостей, Джулия, не есть true компилируемый язык, несмотря на вкусности, которые в нем есть, на нем далеко не всегда получется создать бинарник
А при чём здесь стрелки? Если всё пишете на Julia, она соберёт единый исходник. Если делаете вставки на PyCall, то что ей делать с обвязкой анаконды? Или если использована сторонняя библиотека с каким-нибудь куском на C++ и ресурсами в виде кучи файлов. Как их собрать то?.... На любом языке, если автор не собрал их сам.
> А при чём здесь стрелки? Если всё пишете на Julia, она соберёт
> единый исходник. Если делаете вставки на PyCall, то что ей делать
> с обвязкой анаконды?Я не говорил, что надо скомпилить с зависимостями !
Я говорю только исключительно о Джулии и ее только коде.
Она/он - не есть "compile ahead of time" комилятор.
Джулия использует LLVM JIT compiler.
Вы правда не понимаете разницы между JIT и "compile ahead of time" комилятотор.
> Вы правда не понимаете разницы между JIT и "compile ahead of time" комилятотор.Вам какая разница, если на выходе PackageCompiler выдаёт бинарник в переносимом формате?... Да, для того, чтобы его получить на JIT-компиляторе, надо предварительно запустить трассировку по всему коду, что PackageCompiler и делает, запрашивая точку входя для исполнения. Но сгенерированный машинный код, который на этот момент находится в оперативке, будет сброшен в исполняемый файл. И файл будет один.
> и делает, запрашивая точку входя
> для исполнения. Но сгенерированный машинный код, который на этот момент находится
> в оперативке, будет сброшен в исполняемый файл. И файл будет один.Вы когда с сотнями микросервисов столкнетесь (из своего кармана), то увидите разницу между native compiled program VS dump of JIT
Ну это же не Rust, чтобы каждым бинарником хвалиться.
Строго говоря, ещё есть фиксированный двоичные файлы, которые вмещают в себя и интерпретатор, и скрипты. Но скорость выполнения соответствующая будет.
Спешу тебя огорчить они декомпилируются обратно в питоновский код вплоть до комментариев в коде. И их успешно можно достать и из py2exe и из cx_freeze и из чего угодно.
Если вас не пугает бинарник в полгига конечно. Питоновая программа в бинарном виде… Вы свернули куда-то не туда.
с испльзованием Numpy подтягиваются интеловские библиотеки MKL... и размер становится 800+ Мб, тогда без UPX не обойтись.
Точно, надо пожать файл, что бы наплодить ещё этих грязных страниц, а то 800+ Мб маловато.
Во первых не такие уж они и больше. Во вторых сейчас 2k21 и это никого не пугает.
Изящно набросил. Жаль только, без особого эффекта.
>2k21Сейчас 2021, а не 200021
Ага расскажи это разработчикам вот этой игры https://ru.wikipedia.org/wiki/NBA_2K21
Ты конечно вообще не шаришь. Есть фирма 2К sports, так что 2К это издатель игры.
Пруфы-пруфики: https://ru.wikipedia.org/wiki/NBA_2K_(%D1%81%...)
И как же так получается что названия 2K–2K21 совпадают со следующим годом после выхода игры? И что характерно компания так делает с 2000 года когда она еще не называлась 2K. Может потому что еще 21 год назад всем нормальны людям было понятно что 2K=2000?Давай следующее упражнение для твоего мозга WWE 2K14 https://ru.wikipedia.org/wiki/WWE_2K14 в каком году вышла?
> совпадают со следующим годом после выхода игрыВлияние лунного света на рост телеграфных столбов. 2К тут НАЗВАНИЕ ИЗДАТЕЛЯ.
> Может потому что еще 21 год назад всем нормальны людям было понятно что 2K=2000Именно! Но потом подросло поколение дегенератов, неспособных понять что 200021 != 2021.
>Давай следующее упражнение для твоего мозга WWE 2K14 https://ru.wikipedia.org/wiki/WWE_2K14 в каком году вышла?В 2013-ом)
Нигра с надписью "блейзухи" на футболке в центре обложки.
Безусловно, это прекрасный источник и пример для подражания.
Тебе надо вступить в партию демократов США - через год будешь уважать негров.
Нет, спасибо.
> Если вас не пугает бинарник в полгига конечноИх не пугает. Им же "поставлять", а не "использовать".
Компилируются ли Python-программ с PyQt, matplotlib, pandas и кучей других библиотек?
Есть нюансы, например PyQt в абстракции connect надо явно указывать тип данных в сигналах. Еще есть по мелочи. У меня был PySide и да не сразу как есть но после некоторых приседаний всё заработало. А в негуевых либах у меня проблем не было.
> Компилируются ли Python-программ с PyQt, matplotlib, pandas и кучей других библиотек?Если не используешь флаг "follow-imports", то вопросов нет
Иначе необходимо добавить кучу "nofollow-import-to" и исключить сишные либы. Например, greenlet или pandas
А ещё бывает, что в проекте балуются динамическими импортами. Динамический импорт не отработает, если ты не вкомпилишь статически в бандл соответствующую библиотеку флагом "include-module"Если у тебя проект объёмнее HELLO WORLD, то сборка в один бинарник -- плохая идея, оно просто не соберётся. Рекомендую бить на модули. Для того, чтобы декларативно описать сценарий модульной сборки, я запилил https://pypi.org/project/nuitkabs/ . Если nuitka сопоставима с gcc, то nuitkabs ближе к Makefile. Подрробнее в описании
На pypi кстати есть такая опция можно написать описание к своему пакету и стороннему человеку будет понятно что пакет делает.
> На pypi кстати есть такая опция можно написать описание к своему пакету
> и стороннему человеку будет понятно что пакет делает.Оно там есть, и намного полнее того, что я написал тут. Спасибо, КЭП
Почему бы сразу не написать на с, а не натягивать глаз на глобус?
Си надо еще осилить.
А тут можно буяк-буяк и вперед пользуйтесь.
А что там осиливать? Язык высокого уровня как никак.
Ну да. То, что это не ассемблер, делает язык простым, конечно))
Тут кстати парадокс получается. Ассемблер сложный потому, что он простой
Ассемблер простой, когда понятно как процессор работает. Для Си execution environment формализован, т.е. более-менее понятно, как работает. Парадокс скорее в том, что остальные "очень простые" императивные языки высокого уровня симулирую машину Тьюринга - некую бесконечную хтонь.
Потому что... Да!
Почему нельзя, многие так и делают. На чем писать каждый сам решает, этим вот захотелось так.
Наоборот зачем эти полумеры, лучше сразу писать на Электроне.
> Почему бы сразу не написать на с,Если уж и менять питон на что-то, тогда уж лучше на Nim хотя бы.
На Rust же!
Эй, дырка!
Какие у тебя любопытные ассоциации. Как говаривала одна очень известная личность, кто как обзывается, тот так и называется.
Сразу видно, что тебя минуснули нешарящие :) Nim - офигенная штука, кстати.
Потому что на питоне я напишу, сдам заказчику, получу вознаграждение, заказчик получит прибыль, программа со временем устареет и все будут довольны. А в это время ты все еще будешь писать ее на своем си.
А если писать на раст то тоже будет продолжать писать, но с чувством безопасности.
Я на Delphi напишу в два раза быстрее, красивее и фичастее, чем ты на своем питоне. Но тебе ещё придётся переписывать все с нуля при появлении 3.10
Не напишешь. Delphi - язык со статической типизацией - больше усилий для написания кода. Компилируемый. Тоже временные затраты - отлаживать дольше, нет возможности быстро запускать отдельные куски кода. По поводу фичастости - это вообще шутка неудачная была? Где Delphi, а где - фичи. Впрочем, может что-то изменилось с тех бородатых времен, когда я смотрел на Delphi.
И ещё я не сказал про гораздо более богатый набор библиотек для Питона. Теперь говорю. Delphi до Питона в этом плане, как от Земли до Луны.
И нет, при появлении Питона 3.10 ничего переписывать не придётся.
> со статической типизацией - больше усилий для написания кода.С чего вы взяли, что усилий больше? (а не наоборот)
> Тоже временные затраты - отлаживать дольше
С сего вы взяли? Наоборот проще отлаживать код со внутренними гарантиями.
> нет возможности быстро запускать отдельные куски кода
Unit-тесты уже отменили?
> С чего вы взяли, что усилий больше? (а не наоборот)Да, необходимо уточнение. В больших проектах статическая типизация рулит. В средне-мелких (для чего, собственно, и предназначен Питон) - с ней больше головной боли, чем пользы.
> С сего вы взяли? Наоборот проще отлаживать код со внутренними гарантиями.
Смотрите выше. Если уж так необходим контроль типов, в Питоне есть аннотация типов. Ну и соответствующий инструментарий для контроля.
> Unit-тесты уже отменили?
Их специально писать надо. Но они не всегда нужны: в мелко-средних проектах - не особо. В крупных - да.
Про количество библиотек для Питона и Дельфи и покрываемых ими юзкейсов вы промолчали почему-то. Почему?
А почему же тогда с 2.х на 3.х переход был таким, что около 15-20 лет наработок превратилось в тыкву?
Какие такие крутые билблиотеки? Delphi умеет в БД (FireDAC), в графику (включая DirrectX и OpenGL), в сеть (Indy), в dll, в TouchScreen, в Windows/Linux/Android/MaxOS. Время компиляции - секунды. Дебаг вообще смешно. Там рантайм дебаг, хочь пошагово, хочь - по брейк поинту, хоч - Run to Cursor. И в стек посмотреть можно и в регистры CPU и даже в Thread.
Сейчас бы сравнивать версии 2/3 с 3/3.10
Дельфи не умеет в линейную алгебру, символьную математику, в машинное обучение. Библиотеки для Питона (написанные или на Фортране, или на C) - умеют. Питон в данном случае сильно упрощает жизнь учёным (они не профессиональные программисты, а работу делать надо).Питон умеет в скриптование - он интерпретируемый язык, хотя можно уже и компилировать. Дельфи - не умеет.
Ещё одна сфера Питона - прототипирование. Наваял скелет, стабилизировал API - и давай на чём-то ещё переписывать, более строгом и быстром. Иной раз существенно экономит время.
Есть также веб. Средне-мелкие сайты - его стихия, хотя есть и конкуренты, конечно. Про сайты на Дельфи ничего не слышал. Может не там смотрел.
Ну, не ваша беда, что вы плохо знаете делфи. В определённый этап своей жизни нужно было сделать выбор и вы его сделали правильно. Популярность + деньги. Но это не означает, что делфи не умеет в алгебру (math) в скрипты (Pascal script), Web (сам тоже не видел, но в компонентный базе ВСЕ для этого есть), вот ml похоже действительно не конёк паскаля. А вот учёные, отлично с MathLab справлялись, по крайней мере теплофизики (ни строчки кода знать не нужно)
> Ну, не ваша беда, что вы плохо знаете делфи.Полностью согласен. За Дельфи много не платят. Вакансий тоже, вроде, немного. Ну и язык ничем особо не выдающийся, скучный язык. Так что вы правы - совершенно не беда. :)
> Но это не означает, что делфи не умеет в алгебру (math)
Я имел ввиду ЛИНЕЙНУЮ алгебру (векторы, матрицы, SVD, PCA и подобные вещи). А не просто синус, косинус, экспоненту и прочие банальности.
А в символьную математику Дельфи умеет? В Питоне sympy за это отвечает, например.
А во временные ряды (pandas в Питоне)?> В определённый этап своей жизни нужно было сделать выбор и вы его сделали правильно. Популярность + деньги.
Не угадали. Питон я в принципе не рассматриваю, как способ заработать на жизнь. Это так, для души. Небольшой домашний проект по обработке сигналов в режиме online. Ну и на работе - один из инструментов, причем не основной.
> А вот учёные, отлично с MathLab справлялись, по крайней мере теплофизики (ни строчки кода знать не нужно)
Они-то справлялись, конечно. Но во что это обходилось работодателю? Лицензии сколько-сколько стоили?
> Web (сам тоже не виделэто тебе повезло что не видел. Мы такого монстра образца примерно 1998го года - asp на дельфях, напи...нарисованное мышекликом по готовым модулям человеком, который ничего не понимал ни в http, ни в программировании - до сих пор не можем разобрать.
(комьюнити сайт, да. В смысле - был бы на пихоне, было б только хуже. К счастью, в 98м году нельзя было намышекликать сцайт на впихоне - джанк еще не доизобрели.)
это в собранной то в бинарник программе?
#яснопонятно. В отладчики мы не умеем и даже не слышали. Впрочем, для этого есть тестирование (см. пункт выше).
Потому что возиться с компиляторами, отладчиками, линковщиками, указателями, макроснёй и прочей х-тенью полувековой давности мало у кого есть желание среди нормальных современных людей. До некоторых особо одарённых никак не дойдёт, что идеальное программирование - это когда компьютер понимает мысли человека, а не когда человек насилует свой мозг, чтобы разобраться в том, что нужно компьютеру.Си, кстати, пока никуда не делся. Однако же, надеюсь, в относительно скором будущем его всё-таки похоронят более современные и удобные языки. Процесс уже начался, кстати. Но луддиты упорно стараются не обращать на него внимания, пряча голову в песок, как тот страус, испугавшийся чего-то ранее невиданного. А поезд прогресса тем временем проходит мимо. Ту-ту-у....
Сказочный человек
Вы впервые в жизни увидели своё отражение в зеркале? Гм, забавно.
> Оптимизация пока применима только к коду, компилируемому при помощи GCC.Подскажите им, что для clang оптимизация включается так же - дописать "-O3" к командной строке.
-O4 уже есть.
В статье речь совсем не про О-шки...
Пго есть только у гцц, насколько я знаю. В том числе со сбором информации через автопрофилировщик, но прогнать тесты более актуально. Примерно с гцц-9 пго юзать одно удовольствие, в генту можно любой пакет собрать с пго (правда вручную, при обновлении придётся подменять флаги опять). на практике это конечно пара процентов, но для -O3 разница в скорости запуска и исполнения до 60% доходит (или около того). Вообще, на сегодня нет никакого смысла использовать шланг, раньше он был полезен дополнительными проверками и читаемыми сообщениями об ошибках, но с тех пор гцц улучшили. По скорости компиляции гцц тоже лучше (шланг замедлили основательно).
> Пго есть только у гцц, насколько я знаю.https://releases.llvm.org/4.0.0/tools/clang/docs/UsersManual...
https://clang.llvm.org/docs/UsersManual.html#profiling-with-...
У меня не получилось. В gcc тоже пго было сто лет назад, но до 9 оно было через одно место. Свой софт можно было с пго собрать обложив скриптами, но вот так чтобы любую прогу собрать добавив 2 ключа -- нет.
Отлично, ещё бы в дебчике питонятину откомпилять.
Это ничего не даст. Компиляция сабжем только незначительно ускоряет запуск и больше ничего. Нивелируется недостатками в виде жжора памяти и дополнительным временем на чтение с диска.
Странно, не скомпилированный код же по идее должен тратить такты на обдумывание интерпретатором каждой команды?
Хороший вопрос.
$ cat loop.py
#!/usr/bin/python3.9import time
t0= time.time()
print("Hello")
j = 0
for k in range(0,10):
for i in range(0,50000000):
j = i - j
j = j + k
t1 = time.time() - t0
print("Time elapsed: ", t1)$ ./loop.py
Hello
Time elapsed: 88.54895782470703$ nuitka3 --run loop.py
[...]
Hello
Time elapsed: 49.21110701560974
Ещё немножко этих интерпретаций
$ cat loop.ref
#!/bin/refalGo = <цикл-1 0 0>;
цикл-1 {
10 ?k = ?k;
?k ?j = <цикл-1 <?k + 1> <<цикл-2 0 0> + <?j + ?k>>>;
}цикл-2 {
50000000 ?j = ?j;
?i ?j = <цикл-2 <?i + 1> <?i - ?j>>;
}$ time ./loop.ref
real 0m51,589s
user 0m51,579s
sys 0m0,007s
Кстати, pypy3 loop.py даёт 1.259338617324829 сек.
Спасибо. Сейчас протестирую. Компилируется это pypy3 дольше чем MLton, сразу видно, крутая штука.
> Кстати, pypy3 loop.py даёт 1.259338617324829 сек.На той же машине, где python3.9 давал 88.54895782470703
а nuitka3 -- 49.21110701560974$ pypy3 loop.py
Hello
Time elapsed: 1.1507835388183594Теперь другой вопрос: а зачем nuitka3, когда есть pypy3?
> Теперь другой вопрос: а зачем nuitka3, когда есть pypy3?Потому что, c помощью pypy нельзя сделать готовый бинарник, независимый от интерпретатора.
А какую задачу это решает? Скрыть исходный текст скрипта от посторонних глаз? Или Python не позволяет складировать всё нужное в одну папочку и оттуда запускать?
А где print("Hello Word")? Где измерение времени средствами языка? Про pypi тебе уже написали.
pypy
> А где print("Hello Word")?print("Hello")
> Где измерение времени средствами языка?
import time
t0= time.time()print("Time elapsed: ", t1)
> Про pypi тебе
> уже написали.Вы и вопрос не видели, на который я отвечал?
Я твой скрипт на рефале имеешь ввиду. Мог бы и догадаться.
имеешь -> имел
> Я твой скрипт на рефале имеешь ввиду.А зачем? Включающий время трансляции результат вполне устраивает.
> Мог бы и догадаться.
Догадаться, зачем сообщение про Рефал было написано в ответ на Питон?
1. Затем, что затраты на вывод - они не бесплатные. На измерение времени - тоже.2. Потому что на смартфоне отвечаю, промахнулся немного.
А затраты на чтение исходника и его семантический разбор?
Что про pypy скажешь? Ты как-то в упор не замечаешь его почему-то. Почему?
Потому что pypy собирается в один поток и я всё еще жду. Впрочем, оно не имеет отношения к вопросу, на который я отвечал.
Вопрос был об эффективности компилятора. Ты его сравнил с Рафал. Рафал победил с большим выигрышем. Но почему? То ли цикл просто проигнорировал, например, потому, что переменная больше никак не используется, то ли компилятор пока сырой.
Дождёмся твоих результатов с pypy.
А есть ещё numba, кстати.
Рафал -> рефал
> Вопрос был об эффективности компилятора.В #60 я сравнил python3.9 и nuitka3. Результат 88.5 и 49.2. Что странно для компилятора. В первом приближении ожидается на порядок лучше.
> Ты его сравнил с Рафал. Рафал победил
> с большим выигрышем.51,589s. Выигрыш только у python3.9. Результат примерно как у nuitka3.
> Но почему? То ли цикл просто проигнорировал, например,
> потому, что переменная больше никак не используетсяТест Питона я не писал, а на днях увидел его сравнение с паскалем http://вече.программирование-по-русски.рф/viewtopic.php?f=9&t=470
ну и сравнил заодно. На Рефале вообще так не пишут, мне пришлось специально сохранить семантику циклов. Результат, естественно, проверял -- его возвращает функция цикл-1 в первом предложении (просто здесь эту информацию посчитал лишней). Если точку входа переименовать в go (а не Go) то он выводится:$ time ./loop.ref
Поле зрения:
250000045real 0m50,977s
$ ./loop.py
Hello
Time elapsed: 86.47002148628235
j = 250000045> то ли компилятор пока сырой.
Это мягко сказано. Аноним (49) сообщил о медленной скорости как обыденности.
> Дождёмся твоих результатов с pypy.
> А есть ещё numba, кстати.$ pypy3 loop.py
Hello
Time elapsed: 1.130962610244751
j = 250000045
Спасибо за ответ. Значит, не судьба этому компилятору пока быть быстрым. Продолжаем пользоваться pypy. Вполне возможно, этот компилятор пишут, чтобы руку набить, не преследуя практические цели.
Думается, авторам следовало бы обозначить, что проект исследовательский или что-то в этом роде. Когда публиковал тесты, ожидал, что меня начнут тыкать носом в ключи, которые надо было передать компилятору, что бы результат работал быстро.
Сомневаюсь (хотя мой опыт ограничен), что наличие какого-либо ключа способно увеличить скорость работы откомпилированного кода в десятки раз. Часто речь идёт о десятке-другом процентов, не более.
Не имеет. Но уже просто интересно.
Предположим, что они одинаковы. Или есть сомнения?
Они далеко не одинаковы (1 вызов write() против open() + 6-ти mmap(), одна из которых приводит к чтению с накопителя, не считая собственно разбора), но на фоне 50 сек исполнения - меньше погрешности.
Да только откомпилить для каждого дистрибутива, версии подверсии, под каждое ядро, UEK. И не факт что оно будет один в один работать так же как задумано на обычном питоне.
> ... повышение производительности на 335%Т.е. всего лишь в 3.0-3.5 раз. Питон во столько можно ускорить просто оптимизациями гогнокода. Ради такого мизерного прироста компиляция не нужна.
3 это в синтетике, на самом деле меньше. Подсказка: попробуй откомпилить джангу и когда после танцев это получится узнай что можно использовать в два раза меньше виртуалок для той же производительности.
> Т.е. всего лишь в 3.0-3.5 раз. Питон во столько можно ускорить просто оптимизациями гогнокода. Ради такого мизерного прироста компиляция не нужна.Компиляция, всё-таки, бесплатна по сравнению с переписыванием говнокода.
Компиляция не бесплата т.к. для неё нужно навернуть инфраструктуру, которой в обычной питонячке нет
Это только если ты операционную системы решил скомпилировать.
> Компиляция не бесплата т.к. для неё нужно навернуть инфраструктуру, которой в обычной
> питонячке нетОна сильно беспланее переписывания говнокода на динамически типизированном языке. Многие питонисты кивают на магию тестов, но сложно представить, что говнокод окружён мегатестами. Кстати, unit-тесты придётся тоже переписывать, т.к. архитектурку придётся подровнять.
Это вы описали повышение производительности на 235%
Вы как-то используете наработки shed skin?