Реализация компилируемого Python возможна?

Это не шутка. Питон не зря популярен в data science. Ковыряться огромных массивы данных на нём легко и удобно (пока в производительность не упрёшься).

Ковыряться огромных массивы данных на нём легко и удобно

А, то есть, ты это имел в виду под

Высокая абстрактность.

Ну-ну.

пока в производительность не упрёшься

когда упрешься - биндишь модуль на С/плюсах/фортране и продолжаешь ковыряться

когда упрешься - биндишь модуль на С/плюсах/фортране и продолжаешь ковыряться

Да. Даже при таком угрёбищном подходе скорость разработки получается значительно выше, чем если всё делать с нуля на С/плюсах/фортране.

А, то есть, ты это имел в виду под

Высокая абстрактность.

Это её следствие.

Это не следствие, по крайней мере, не в данном случае.

Не согласен. Возможность создавать абстрактные методы и свойства типов значительно уменьшает кол-во кода, которое нужно для решения задачи, т.к. его легко использовать для разных задач, без переписывания интерфейса. Да, я знаю, абстрактные типы есть и в фортране/c++/и т.д., но они не такие гибкие, как в питоне.

в фортране/c++/и т.д.

Опять про говно мамонта. Сказал бы сразу: в питоне высокая абстракция ПО СРАВНЕНИЮ с фортраном, никто бы и не спорил.

Да. Даже при таком угрёбищном подходе

Чем же он угребищный то?! Отличный подход, в числодробилках там прямо вот вообще в кассу…

Сказал бы сразу: в питоне высокая абстракция ПО СРАВНЕНИЮ с фортраном, никто бы и не спорил.

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

Чем же он угребищный то?!

Угрёбищный тем, что нужно использовать компот из разных языков, со всеми их недостатками. Это конечно работает, но по слухам так делать совсем не обязательно, в теории.

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

И со всеми их достоинствами. Можно так не делать, но если вы хотите быстрое вычислительное ядро и удобный и компактный интерфейс, то либо используете связку из двух ЯП, либо упарываетесь по всяким плюсовым извращениям что бы получить что то похожее на простой питоний интерфейс который идет почти из коробки (ну с парой своих либ м.б.).

Там джулия вроде обещает более элегантное решение проблем. Я потыкал, почитал доки, вроде бы имеет больше смысла, чем питон для моих задач. Уже год упрашиваю админов установить таки на кластере, попробовать на реальных задачах. Всё у них руки не доходят. Пока что напрягают всех переделывать древние скрипты на питон3. Что же, переделываем.

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

ЗЫ да, переход на py3 это подстава;-(

Я не верю в чудеса.

Там никаких чудес. Всё по науке. Всё логично.

ну так это будет работать медленнее чем тот же фортран сделанный прямыми руками.

Медленнее чем интел фортран, это наверняка, с ним тяжело спорить на интел платформах. Насчёт других версий фортрана не уверен. Да даже если медленнее фортрана, но не настолько как питон, это уже имеет смысл для большого круга задач.

С «чистым» питоном сравниваться вообще нет смысла. Да, numpy какой нить они обгонят, это несложно. Связку питон-плюсы/фортран (правильно написанные) обогнать не смогут, даже приблизится не смогут.

Ну да, наверное имеет какой то смысл… Не, больше ЯП хороших и разных это всегда хорошо!

Связку питон-плюсы/фортран (правильно написанные) обогнать не смогут, даже приблизится не смогут.

По производительности наврядли обогнать, сравняться - легко на многих тестах. А вот по скорости разработки - это надо посмотреть. Я согласен, что можно изолировать медленные куски кода на питоне, ускорить их, и это не так сложно, поскольку соответствующие инструменты есть. Но все эти f2py/cython/numba добавляют таки гемороя в процесс разработки.

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

Жуля хоть и не делает чудеса, но все равно позволяет писать достаточно быстрый код без запарок, и, самое главное, без лютого гемора питоньих биндингов, которые представляют из себя «третий язык».

лютого гемора питоньих биндингов,

У меня весь биндинг обычно занимает три строки (включая вообще всю сборку), дальше работает swig и давно написанный шаблонный Makefile. ЧЯНТД?

У меня весь биндинг обычно занимает три строки (включая вообще всю сборку), дальше работает swig и давно написанный шаблонный Makefile. ЧЯНТД?

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

Вообще то я биндю классы со сложными полями и кучей функций со сложными аргументами.

Вообще то я биндю классы со сложными полями и кучей функций со сложными аргументами

Да, я посмотрел SWIG — действительно, впечатляет. Хоть и не родной фейс, и есть некоторые проблемы ( http://www.swig.org/Doc4.0/Python.html#Python_nn40 ), но в общем я вынужден согласиться, что для для питона возможно быстро сделать работающие достаточно сложные биндинги.

Ну вообще конечно у свига есть некоторые проблемы с инстацированием шаблонов и ещё всяким разным, но я научился их решать (и даже хакнул их систему типов для своих нужд:-)).

Так до да, если нужно пробросить кучу толстых классов с минимумом телодвижений - самое оно.

http://a-iv.ru/pyart/cpp2py.pdf может пригодиться.