Транспайлер-цепь Python → 11l → C++ [для ускорения Python-кода и не только]

[Tanner]

Это как-то подозрительно хорошо.

А имеет смысл попробовать ускорить достаточно сложный проект? Этот, например?

[alextretyak]

На данном этапе, увы, нет.
В этом проекте слишком много чего импортируется и слишком много возможностей Python используется.
[[[А декораторы поддерживать вообще не планируется.]]]

[Tanner]

Жаль.

[alextretyak]

С моей точки зрения они только запутывают [на основе опыта перевода этого кода с декоратором @method — код без декоратора получился более понятным].
А "стандартные" декораторы (@property, @classmethod, @staticmethod), имхо, лучше поддерживать в синтаксисе языка программирования.

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

[gnomeby]

Это с вашей точки зрения. А с точки опытного веб-разработчика, декораторы — отличный способ не сильно увеличивая код определить правила входа в конечные точки веб-приложения (CSRF проверки, разрешенные http методы, правила кеширования и пр.).

[alextretyak]

Очень бы хотелось увидеть пример хорошего использования декораторов.
Вы не могли бы дать ссылочку на код [если он в open source, разумеется]?
Буду крайне признателен.

[gnomeby]

Вот прямо на главной:
flask.pocoo.org

Вот посложнее:
docs.python.org/3/library/contextlib.html

[asm0dey]

скажем так — я не понимаю как сделать flexget без декораторов…

[Tyiler]

Прочитал мельком.
Вопрос возник: если так все хорошо получилось преобразовать, то почему бы сразу не сделать C++ из Python, без прослойки 11l (думаю, что никому не нужной — еще один язык? — нее!)

[alextretyak]

Ну, начиналось всё с преобразователя 11l → C++. О компиляции/ускорении кода на Python я тогда вообще не думал.
И лишь спустя полгода была начата работа над Python → 11l.
Почему не над Python → C++?
Ну, во-первых, 11l гораздо ближе к Python, чем C++ к Python.
Во-вторых, не буду скрывать, проект Python → 11l задумывался с целью популяризации языка 11l.

[Tyiler]

почитал прошлые ваши статьи про 11l.
там вам пытались вправить мозги. я тоже самое скажу — забейте на 11l.
Вот сделать переводчик (Транспайлер) быстрый — Python -> C++, а потом еще и вызов компиляции из коробки для него сразу, — было бы, наверно, полезно.

[gnomeby]

Таких проектов уже много и так.

[alextretyak]

А можете привести самые удачные?
Просто я толковых проектов не нашёл (помимо упомянутых в статье Nuitka и Shed Skin, я попробовал py14, Pythran и Py2C).

[gnomeby]

Да, по сути эти проекты и так в вашей статье. Но самый удачный проект — Cython. Он конечно вводит статическую типизацию, но одновременно и самый удобный в применении и в него можно при желании скомпилить многое оптимизируя кусками, без сильных переделок, а это самое важное. Это гораздо важнее возможности транслировать любой код на питоне в Си код.

[alextretyak]

Главная проблема Cython [и главное препятствие на пути его широкого распространения] с моей т.з. — аннотации типов в нём задаются по-своему, отлично от Python Type Hints (доступных начиная с Python 3.5).

А также, насколько я понял, нет достаточно удобного отладчика для Cython (кроме DDD ничего не нашёл). [Для 11l это не такая острая проблема, так как можно отлаживать Python-код перед отдачей его транспайлеру Python → 11l, а с Cython так не получится, так как код на нём написанный не совместим с Python.]

[gnomeby]

Главное препятствие на пути широкого распространения любой альтернативки CPython — то что это никому не нужно. Кроме специализированных случаев: pypy, numpy, cython, когда люди готовы специально потратить время на адаптацию алгоритмов. Никто не любит ограничений любых либ и трансляторов, ибо питон любят в том числе за синтаксис, иначе проще взять Go/Swift/Rust и пилить более быстрое ПО.

Если ваш транслятор хорош и действительно транслирует обычный питон-код, тогда его элементы можно включить в сам CPython и получить ускорение. И вот от этого никто бы не отказался. Но то-то мне подсказывает, что вы также будете предоставлять ограниченный питон.

[Tyiler]

в продолжение.
я бы стал делать через LLVM, те попробовал бы сделать байт код из Python кода понятный LLVM.
может быть уже есть такие решения, посмотреть как сделаны, проверить скорость — и если есть куда расти, то…

[monester]

А как у вас с безопасностью? Что будет есть обратиться за приделы списка элементов?

[alextretyak]

Также как в Python: обращение за пределы массива бросает исключение IndexError.

[gnomeby]

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

[gnomeby]

Ну и вдобавок:
* Напишите простенький веб-фреймворк на языке и на нём же запустите собственный сайт.
* Для коннекторов к базе используйте линковку Си драйвера любимой базы.
* Не забудьте про шаблонизатор
* Не забудьте про кеш
* И вам понадобится какой-нибудь FastCgi протокол

Вот когда вы это всё сделаете, может быть вы что-то ещё поймёте.

[Tihon_V]

А где можно посмотреть список/план фич?
IMHO: Стоит сранить с grumpy (golang).

[Zanak]

А на nim вы смотрели (если размышлять о трансляции Python->промежуточный_язык->C++)? Мне, после питона, на нем показалось вполне комфортно, жаль, он пока не особо востребован в плане коммерческой разработки.
Не то, чтобы я был против еще одного языка. Пока появилась автомобильная промышленность, автомобили строили именно энтузиасты. Думаю здесь происходит нечто подобное.
Сам язык (я про 11l), его документацию, просмотрел по диагонали, и, если честно, не зацепило. Еще один язык с непривычным синтаксисом и смутными перспективами. Я подожду с его изучением.

[Ktulhy]

Поддерживаются ли классы?

[alextretyak]

Да, только они называются типами (как в Go).
Коротенький пример есть в документации.
По умолчанию типы в 11l являются "типами-значениями" [а не "типами-ссылками"] и работают как структуры (struct) в C или C++.
В случае, когда тип Type ссылается сам на себя, Type заменяется на SharedPtr<Type> (см. первый пример отсюда).
В случае, когда тип Type содержит виртуальные функции, Type заменяется на std::unique_ptr<Type> (пример).

[alextretyak]

Прекращение поддержки Mercurial в Bitbucket :( сломало ): две последние ссылки из данного комментария.
Вот новые ссылки:
… Type заменяется на SharedPtr<Type> (см. первый пример отсюда).
… Type заменяется на std::unique_ptr<Type> (пример).

Также хочу заметить, что такое поведение планируется пересмотреть, и в новой версии транспайлера 11l → C++ Type будет заменяться на std::unique_ptr<Type> всегда когда это возможно (т.е. при отсутствии в коде вызова share(obj) с объектом obj типа Type).

[Pappageno]

while (true)
{
    switch (instr[i])
    {
    case '[':
        nesting_level++;
        break;
    case ']':
        if (--nesting_level == 0)
            goto break_;
        break;
    }
    i++;
    ...
}
break_:

А вы специально используете эти скобочки, чтобы визуально увеличить кол-во C++-кода? В контексте питона(и 11l) вы не можете сказать «мне удобнее/привычней» выделять блоки «скобкой на новой строке», а не отступом.

[alextretyak]

Эмм… Не понял, если честно, ваш вопрос. Вы имеете в виду, почему не так:

while (true) {
    switch (instr[i]) {
...

Или как вы предлагаете не "увеличивать кол-во C++-кода"? Ведь фигурные скобки в этом примере необходимы и являются требованием языка C++.

В контексте питона(и 11l) вы не можете сказать «мне удобнее/привычней» выделять блоки «скобкой на новой строке», а не отступом.

Почему не могу? 11l позволяет выделять блоки как отступом так и/или фигурными скобками.

[Pappageno]

Эмм… Не понял, если честно, ваш вопрос. Вы имеете в виду, почему не так:

Да.

11l позволяет выделять блоки

Это хорошо, но это не распространяется на питон, как и на привычки/видение пользователей питона, в том числе и вас(все ваши примеры без скобочек) и ЦА ваших трудов.

Вот я спрашиваю, чем обусловлен такой стиль? А мой же вопрос обусловлен древними холиварами на тему «в c++ есть скобочки, а у нас нет — наш код компактней». Вот я и думаю — это всё идёт с тех времен, либо что-то ещё.