javascript, php, perl, tcl, lisp, bash

Оживлятор веб-страничек, шаблонизатор, гольфист-однострочник, описатель гуйни, расчесыватель ЧСВ, склеиватель команд. Итого, ни одного ЯП общего назначение, всё это классическая скриптуха, кроме лиспа, который где-то в ином измерении.

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

Чем это не удобная? Универсальная, и код даже чисто логически выглядит лучше. Из конкурентов может быть жс, но колбэк дривен программинг это явно другое. И потом, берёт всё лучшее от конкурентов, можно писать в удобном стиле.

Ну и C, и С++, и (кажется) Rust проектировались по принципу минимальных добавлений в рантайм. Ну да, в плюсах есть лишний уровень косвенной адресации для позднего связывания методов (без которого ООП — не ООП), но и только. И да, все эти си, кресты и ржавые в какой-то мере «одинаково плохо подходят для любых (широкого круга, как минимум) задач.» Вот какого хрена программист на сях или плюсах должен думать об управлении памятью, когда он может взять Go или D и перестать думать. Так что это языки общего назначения, как не крути, вы же сами говорите «эффективность везде приятна». И очень-очень часто таким языкам альтернативы нет и (вероятно ещё долго) не будет. Мы конечно можем называть эти языки системными — но Gimp (Krita), Audacity, офисные программы, куча игрушек и т.д. и т.п. с какого перепуга стали системой? Вот где не используется C++? В веб-разработке? Наличие примерно десятка веб-фреймворков на нём, говорит что таки используется (если и не в мейнстриме, то для обеспечения альтернативного веб-интерфейса десктопной программы — уж точно).

javascript

Оно конечно без Mozilla (которая тогда ещё была внутренним кодовым именем продукта Netscape) фиг бы кто этим пользоваться стал. Но сейчас он расползся куда можно и куда нельзя, и ничего ты с этим не сделаешь. Ну и язык с тех времён таки несколько изменился, как и следующий за ним по списку php.

tcl

tcl это не только префикс к tk… Ещё это bash для не курильщиков, встраиваемый язык (пусть и сильно потеснённый lua), lisp без скобочек (ну и без списков, по крайней мере без списков в осеновании всего)

lisp

способ описать некоторые базовые концепции и парадигмы программирования (sicp и прочее, MIT конечно заменило этот курс на нечто на базе питона, но тем хуже для MIT и всех нас), способ программирования для тех, кому излишняя абстрактность мышления мешает работать с более другими языками, простой динамический язык где JIT и т.п. реализуется заметно проще, чем в этих самых более других языках (собственно sbcl заметно больше лет чем v8, PyPy и прочим, и компилится он на порядок быстрее).

Ну и да, язык расширения emacs (и не только emacs)

И да Python — точно такая-же скриптуха, за счёт кучи батареек полезшая всюду (конкурирующая в этой вездесущести с JS). В каком то смысле — да, лучшее из всех миров, но на практике — как есть New Basic (примерно с тем же уровнем элегантности).

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

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

На самом деле только тыкал палочкой в ctypes. Потом вычитал, что он тормозной и нужно пользоваться cffi.

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

Я думал что сейчас все биндинги для Python пишут через cffi. Надо будет экспериментировать.

Так что это языки общего назначения

Да. Как и питоны с рубями.

очень-очень часто таким языкам альтернативы нет

Это было истиной в давно устаревших компах, но уже давно не так, и дальше - хуже. Задай себе вопрос: какой процент из последних написанных тобой программ «не успевали?». Если, вдруг, больше 10 - задай такой же вопрос сотне случайных писак в инетах. Даю волосы на осечение, что «очень-очень часто» окажется очень-очень преувеличенным.

Пусть лучше жс везде лезет.

Согласился бы, если бы на десктопе к нему не прилагался electron.

Ок, замени «очень часто» на «в массово тиражируемых программах длительного использования». К примеру, пользоваться пинтой вместо гимпа на постоянной основе я категорически не согласен. На питоне, кажется, такое никто писать (к счастью) не пытается.

И на чём же там пишут высокопроизводительный код?

Непосредственно на самом языке. Применение FFI на каждый чих это чуть ли не исключительно питоническая практика.

Посравнивай здесь: https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/python.html

На днях, кстати, прожарил языки рекурсивной фибоначей: Код-инжекшены в убогом питон (комментарий)

Например, в каком из этих языков есть быстрая арифметика произвольной точности без сишных расширений?

А в каком из этих языков делают запросы в РСУБД без SQL? Давай без этого тупняка. Для начала ты притягиваешь то, для чего большинство этих языков не предназначено, а потом вставляешь слово «быстро», которое можно выкрутить так сильно, как тебе понравится.

Я думал что сейчас все биндинги для Python пишут через cffi

Так себе развлечение. Попробуй SWIG или Boost.Python (C++), так гораздо удобнее и быстрее по скорости разработки. А что будет быстро или нет, в твоём конкретном случае, лучше выяснить протестировав это на практике, а не читая что попало.

Я думал что сейчас все биндинги для Python пишут через cffi.

Биндинги пишут на нативных экстеншинах. На FFI (ctypes, cffi) норм только на винде к винапи. FFI основан на загрузке либы по имени. Напр. нужна либа libname.so но в дистре такого симлинка нет, а есть только libname-3.567.so И все, такой биндинг уже не работает.

glob тебе поможет

Попробуй SWIG или Boost.Python (C++), так гораздо удобнее и быстрее по скорости разработки.

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

Чота во многи проектах хреново помогает. Но не вопрос - можно выполнять задачи компилятора и линкера на питоне. Только толку то с этого?

К примеру, пользоваться

После этого можно ставить точку. Как только в системе появляется «пользователь», место необходимости «сей» сужается до очень заднего. Пользователь - самая медленная часть системы, и если он там есть, ускорять код уже нет смысла:

1. Пока/если мы чего-то от него ждём, скорость кода несущественна. 2. После того, как дождались, скорость появления ответа монотонно зависит от объёма данных, которые нужно обработать за четверть секунды — меньше человеки не заметят, больше - будут раздражены тормозами. И там только 4 варианта: 2.1 данных мало = их что угодно успеет обработать. 2.2 данных много = их ничего не успеет обработать = достаточно вывести «cofee time»(см. 2.1) и обеспечить надёжный оффлайн, что проще там, где проще. 2.3 данных ровно столько, чтобы си успели а питоны нет — очень узкий диапазон задач, 2.4, самый популярный — всё отведенное время съедает коммуникация - см. 2.2

Допустим, питоны в 100 раз медленнее. Это определяет «сишную» нишу как «то, на что питону нужно от 1/4 до 25 секунд процессорного времени». Иэ этого следует вычесть то, что можно посчитать, пока юзер думал и вводил, и всё, что выполняется не во «внутренних циклах». Что останется?

Ой, ну растровый графический редактор — эта не та программа, где пользователь — самое слабое звено. Подкрутить яркость контрастность у фотки с мобильника как раз хватит и пинты, и, наверное, чего ещё более «скриптового», но когда речь про большие картинки и/или сложные эффекты — pardon. Есле речь про пиксельарт, дело другое, пиксельарт можно и в vim «рисовать» (.xbm и окрестности), хотя всякие GrafX2 и aseprite/LibreSprite тоже (традиционно) на сях пишут.

Хотят если речь о нейросети, с двумя кнопками «сделать зашибись» и «закосить под Ван-Гога», ок, там питон между потрохами нейросети и этими двумя кнопками — традиционная прослойка.

Я как раз советую по делу.

На самом деле только тыкал палочкой в ctypes. Потом вычитал…

Человек ничего в этом не смыслит, и даже если тему это действительно нужно, то, наверняка, производительности с Boost.Python ему хватит за глаза. И, в любом случае, когда идёт речь про питон, речь идёт и о скорости разработки, так что генераторы актуальны как минимум на стадии прототипа.

Непосредственно на самом языке.

Это не так. Пришлось выписать в отдельный тред, а то слишком длинно вышло: Эффективная оптимизация. Что такое Cython. — подробности для тех, кто не занимается низкоуровщиной на питоне.

Но если вкратце... Питон в этом не уникален. Почти во всех языки есть возможности низкоуровневой оптимизации, расширения на си через FFI/JNI/и т.д. Есть unsafe код в rust и c#. Даже в паскале и си есть ассемблерные вставки. Не удивительно, что кто-то придумал аналог и для питона.

Применение FFI на каждый чих это чуть ли не исключительно питоническая практика.

Во всех языках вычислительный код всегда выносился во внешние библиотеки, будь то арифметика произвольной точности, кодеки, архиваторы, шифрование, или что угодно другое. И во всех языках пишут биндинги к внешним либам. Просто в питоне это максимально упростили.

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

Эти языки не предназначены для вычислительных задач? Интересно...

Посравнивай здесь: https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/python.html

Ещё интереснее! По этой ссылке ТОЛЬКО вычислительные задачи, а в топе там языки, использующие внешние либы... Но ведь кто-то только что утверждал, что большинство языков для них не предназначено... Так что же мы тогда сравниваем?

Почти во всех языки есть возможности низкоуровневой оптимизации

Это само собой разумеется. Собственно, отсюда и был ответ:

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

Я даже отвечать на эту тупость не буду.

Возможность оптимизации и её необходимость — вещи разные. И нигде, или практически нигде, кроме питона этот вопрос не встаёт колом.

Просто в питоне это максимально упростили

Просто в питоне это особенно актуально.

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

Эти языки не предназначены для вычислительных задач?

Разумеется. JavaScript изначально предназначен для обработки нажатий на кнопочки, и даже сильно расширив границы в математику он не залез, вычислений на нём не делают. Bash — не язык общего назначения, ни о каких вычислениях нет и речи. PHP — это такой разросшийся шаблонизатор HTML, на котором вычисления никто не делает. Перл — это когда мало баша и очень хочется райтонли, тоже не для вычислений. Tcl — вообще не понятно зачем, мб на нём кто-то что-то и считает, я не в курсе. Ничего не знаю про лисп, кроме того, что не хочу на нём писать, но что-то мне подсказывает, что реализации языка из 50х по определению должны быть производительным, я не прав? Java — очень быстрая сама по себе, без чего-либо из вне, уж не знаю как широко её используют для вычиследний, ибо подозреваю проблему с матрицами, но в целом она максимально производительна, писать можно что угодно.

Ещё интереснее! По этой ссылке ТОЛЬКО вычислительные задачи

Внезапно! А как ещё бенчить производительность языка, IO чтоли гонять? Конечно же нет.

Но ведь кто-то только что утверждал, что большинство языков для них не предназначено…

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

Так что же мы тогда сравниваем?

Коней в вакууме. Такие тесты не зря называются синтетическими.

а в топе там языки, использующие внешние либы…

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

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

На днях, кстати, прожарил языки рекурсивной фибоначей: Код-инжекшены в убогом питон

Там ошибка. cython и си на таком тесте должны быть равны с точностью до погрешности. Конкретно, ошибка в строке: cdef fib(int n): — не указан тип возвращаемого значения, должно быть cdef int fib(int n):. А в целом — отличный тест, хороший способ оценить оверхед на вызов функции в разных языках.

«Вот из этого получается 3700 строк на C (в которые я даже не пытался смотреть)»

Его обычно и не смотрят. Смотрят в .html, который генерит cython --annotate ....

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

А, ок, теперь, кажется, понятно... Речь о том, что в питоне не сильно заботятся о скорости стандартной библиотеки? Есть такое. Это отдано на откуп сообществу. Почти все оптимизированные версии — это сторонняя разработка, по интерфейсу совместимая со стандартной библиотекой питона.

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

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

Ну, на питоне можно решать все задачи. Некоторые так развлекаются — «pure python implementation of XXX». Но обычно оптимальнее воспользоваться для этого готовой либой, даже если она на другом языке.

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

Не, в тех тестах во многих языках используются нестандартные библиотеки. В той же pidigits рулят те, у кого есть биндинги к libgmp. См.например, код на Java

Там ошибка. cython и си на таком тесте должны быть равны с точностью до погрешности

Спасибо. Результаты действительно эквивалентные.

В той же pidigits рулят те, у кого есть биндинги к libgmp

Тогда смысл этих конкретных тестов не ясен.

Пользователь - самая медленная часть системы, и если он там есть, ускорять код уже нет смысла:

Но все продолжают писать гуи на C++ почему-то, а на жабу и електрон юзеры ругаются страшными словами.

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

Это прекрасно: стандартная либа, которой нежелательно пользоваться. На самом деле никакая она не стандартная (нет стандарта) и не референсная, просто рандомно пакуют что-то вместе с интерпретатором. В любой версии могут что-то выкинуть или поменять апи, и ты останешься обтекать.

Не совсем так. Перед попаданием у этот перечень к либам предъявляются определённые ожидания, которым они должны удовлетворять. А когда апи меняли? Прям так взяли и поменяли? Или было лет 10 на то чтобы обновить свое дерьмо?

Все с точностью до наоборот: гуи сейчас пишут на электроне (или мобильные react-*), а ругаются те, кто в жизни сложнее hello world не писал.

когда речь про большие картинки и/или сложные эффекты

Скорее всего «сложный эффект» представляет собой пару красивых формул в цикле по пикселям. Незначительная часть кода, по сравнению с ублажением пользователя свистками-бубенцами.

традиционно на сях пишут

Это отдельный феномен. Допустим, у нас есть задача, одни части которой «чуть» проще решается инструментом Ф, а другие - инструментом Ы. Есть 2 (очевидные - может ещё кто вспомнит) настоящие причины использовать только Ы: Й) автор недостаточно знаком с Ф. Ц) Ф-Ы интерфейс слишком «дорогой».

Й является разумной только если это (пред)последний проект в жизни автора, и в мире нет специалистов по Ф. Не считается.

Ц есть простая техническая проблема «как сделать достаточно дешёвый интерфейс», которую нужно решить один раз, и, скорее всего, это уже сделано. Т.о. это останется валидным, если выигрыш от Ф слишком незначительный, чтобы перевесить расходы на переключение.

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

Ничто из этого не имеет права на участие в процессе, в идеальном мире правильных решений.

Скорее всего «сложный эффект» представляет собой пару красивых формул в цикле по пикселям.

Это очень сильное упрощение. Вот к примеру, описание математики по ту сторону популярного плагина Liquid Rescale.

Незначительная часть кода, по сравнению с ублажением пользователя свистками-бубенцами.

Простите, но вы ерунду пишите. Расскажите о многочисленых свистелках в интерфейсе GIMP, тормозящих его работу. Мы вас внимательно слушаем, ваше мнение очень важно для нас. Да покажите хотя бы заметные преимущества ImageMagick перед GIMPом по скорости (не говоря о том, что для индивидуальной работы превью используемого эффекта и возможность отмены и комбинирования — очень важна). А теперь тоже самое — для Blender. Вот лично я люблю PovRay, но почему народ таки предпочитает первый продукт? И почему они оба написаны на C/C++ а не на питоне или JavaScript?

В контексте UI на сях

Я бы не стал сводить даже какой-нибудь Aseprite к чистому UI. Не, редакторы спрайтов и векторов на JS уже пишут (а потому-что online), как и собственно игры (а потому что то же самое), но когда это всё запускается более-менее одновременно (нормальная для разработчика ситуация) почувствовать что «железо жмёт» не так сложно, особенно если ты, к примеру, из-за мобильности в пространстве предпочитаешь компактные ноутбуки. А если ты разрабатываешь, к примеру, стратегическую игру со сложной и глубокой симуляцией, то там и даже не используя графику можно с не такими уж минимальными требованиями к ресурсам столкнуться.

Ладно, бог с ней с графикой, бог с ними с играми, но да, я всё ещё предпочитаю текстовые редакторы с ядром на C, C++, FreePascal в конце-то концов (vim, emacs, scintilla etc.) которые не тормозят, и показывают приемлимые результаты на по-настоящему больших текстах, какую бы скриптовую обвеску «для UI и бизнес логики» мы на них не навешали. Внешний слой (те самые свистки и бубенцы) может быть на питоне, луа, тикле или чём угодно (я сейчас больше про scintilla, в emacs то lisp) — но ядро — нет. Ок, Microsoft сделала свой VSCode на чистом JS, но когда для того, чтобы обеспечить нормальную работу текстового редактора им пришлось применить довольно изошрённую многопоточность и умную деградацию возможностей при нехватке ресурсов — простите, но вы (все, с MS во главе) втираете мне какую-то дичь.

И да, принесите мне в студию мало-мальски популярный текстовый редактор на Питоне или чём-то аналогичном (c js то всё ясно — он вездесущ, и причины можно понять), без сцайнтилы и чего-то похожего «внутре» — поговорим за свистки и бубенцы дальше, а пока — Dixi.

Даже скриптовый обвес может некисло тормозить, если жирный. А уж если все примитивы на скриптоте сделать, даже трудно представить. Обычно гуи на питоне это пара формочек, странно если б такое еще тормозило. Как tcl/tk - вроде пишешь на зверски медленной скриптоте, а работает нормально, потому что чуть не каждая команда это обвзяка сишного кода. И такое канает пока не понадобится свой виджет или тяжелая обработка данных. И тут переключаемся полностью на сторону C. В результате программа то больше на C. Потом думаешь, а не проще ли было сразу на плюсах всё писать.

Кстати, в блендере как раз заметная часть UI вынесена на Python. Но это как раз то, о чём я писал про текстовые редакторы.

Так Sublime Text, номер 1 текстовый редактор в мире, не Scintilla по-моему?

Сейчас ещё раз посмотрел, да всё верно, нечто двоичное на 7 + 8 метров, похоже, на плюсах написанное, и да, не очень похожее на Scintilla, видимо, что-то своё, а рядом лежит «бизнес»-логика на питоне. Редактор-то по любому не на Питоне, так что сути это не меняет.

Человек ничего в этом не смыслит, и даже если ему это действительно нужно...

то он идет на pypi или stackoverflow и ищет готовое решение. Потому как интеграция с нативной либой подразумевает достаточно хорошие знания в сях и подкапотной механики питона или ffi.

когда идёт речь про питон, речь идёт и о скорости разработки

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

Потом думаешь, а не проще ли было сразу на плюсах всё писать.

https://sk1project.net - вполне зрелый векторный редактор аля CorelDRAW, написанный на питоне. На сях/плюсах теми силами и за то количество времени, что потрачено, реализовать было бы нереально.

Вот к примеру, описание математики

Второе предложение:)

We present a simple image operator

Завтра попробую таки почитать, сейчас глаза устали.

Я бы не стал сводить ... к чистому UI

УЙ там вообще для примера — в любой более-менее сложной программе присутствует изрядное количество нечувствительного к скорости клея и прочей одноразовости. Зачем они пишут это на том[же], что сложнее? Я не знаю, у меня только гипотезы, одна другой обиднее. Может то-то приличную причину назвать?

Тебе надо в соседний тред, где электрон обсуждают :D

re: описание математики

Она таки простая. Очень.

И прям очень быстрая на достаточно больших изображениях? Настолько простая и быстрая, что стоит писать всё это на скриптоте?

Тогда смысл этих конкретных тестов не ясен.

Это проверка на пригодность языка для той или иной задачи.

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

Важна не только скорость, но и код, которым она достигается.

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

простая и быстрая, что стоит писать всё это на скриптоте

Спорим с соломенным человечком? Напоминаю:

«сложный эффект» представляет собой пару красивых формул в цикле по пикселям

«Пара красивых формул» хороша тем, что без больших затрат пишется на том, что «быстрее работает»(или, обобщая, лучше по каким угодно иным критериям). «Сложное» это не то, что было трудно придумать или будет трудно реализовать в заданных ограничениях. «Сложное» это состоящее из многих компонент. Клеить оные не тем, чем удобно клеить — бросать время на энтропию.

Зачем они пишут это на том[же], что сложнее? Я не знаю, у меня только гипотезы, одна другой обиднее. Может то-то приличную причину назвать?

Потому что удобнее и проще делать всё на одном языке, даже если этот язык сложный. Ну так человеки устроены, полиглоты редко встречаются. Если кто-то уже хорошо знает C++, на кой ему еще питон, который вообще-то не самый простой язык. Все забыли уже, что скриптовые языки придумали для расширения программ пользователями. Программисты вообще не должны этим заморачиваться. Разве что задача решаема целиком на питоне, и вы наняли именно питонокодера.

Время рабей прошло лет 5 назад, навсегда. Crystal и то актуальней.

в твоем выдуманном мире

Ты же в курсе что раби взлетели только благодаря тому что питон при прочих равных криво с юникодом работал? Вон и из игровых движков раби давно повыкидывали, на жс заменили. Будь рельсы на питоне, о рабях никто и не знал бы (кроме меня, я помню их ещё в начале нулевых).

Ты же в курсе что раби взлетели только благодаря тому что питон при прочих равных криво с юникодом работал?

Это что за городские легенды? Когда раби взлетал там вовсе юникода не было, прикручивали на коленке.

Будь рельсы на питоне

Мегалол. Прошли годы, уже везде есть рельсоподобные фреймворки. Кроме пистона.