Pythons фрэймворки. Скорость.

Простота инструмента на Python для очень узкой области - это безусловно краеугольный недостаток php.

Мы про веб говорим. Если вы хотите поговорить о тонкостях разработки драйверов на php - создайте соответствующую тему.

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

Я пытаюсь только, чтобы тот, кто зашёл в эту тему, не слушал мифов про «php освоить легче всего» и не стал создавать новых php-велосипедов. Пусть лучше на bottle.py посмотрит, если он новичок, и тем самым расширит опыт и базу bottle.py-приложений.

Меня в этом треде интересуют высказывания про реальные косяки php.

Умирает после каждого запроса (костыли типа мемкешей не исправляют всех проблем, при этом усложняя приложение),

Не очень хорошо дружит с utf-8 (про mb_ или даже перегрузку строковых функций новичок узнает только тогда, когда набьёт шишек, при этом того же strtr в unicode нет),

Культура поощряет писать мешанину из html и php, это наиболее простой путь, и куча приложений грешит этим. Также часто используются строки для sql-запросов, откуда регулярно находят sql-injection. Т.е., можно написать и правильно, но это долго, сложно и нудно, и поэтому чаще всего мы видим то, что видим,

Режим «что вижу, то и пою», когда обращение идёт напрямую к файлам. Из этого - куча неприятностей: нет нормальных роутов (все костыли сервероспецифичны и привязывают к конкретному серверу), небезопасно (нужно хранить файлы данных так, чтобы сервер их не отдавал, и это опять же сервероспецифично),

Тормоза (приложения на php, вследствие всего перечисленного, умудряются неслабо тормозить).

вот

И это только по исполнению, не касаясь самих возможностей языка.

Раз так, вот и ответь, кто такой нормальный программист.

Программист, которые умеет писать хороший, надежный, понятный код.

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

Не очень понял вопрос, но, по-моему, ты пытаешься сравнивать язык php и фреймворк для конкретной задачи на python. На php тоже есть библиотеки и фреймворки, которые объединяют множество рутинных действий в более крупные, а что-то вообще делают неявно, незаметно для программиста. Ну, т.е. если тебе нужен шаблонизатор для генерации html страницы, то тебе нужно использовать шаблонизатор на php или python, а не функцию print.

Это неверно, php не так уж и лёгок для написания полноценного приложения начинающим - это раз, и bottle.py намного проще - это два.

Попробуй сравнить фреймворк на php с фреймворком на python, если тебе это интересно. Наверняка во фреймворках на php тоже есть куча упрощений для написания веб приложений. Я совсем не в теме.

Меня интересуют слабые стороны php для написания в первую очередь скриптов для администрирования и для веб приложений (не особо нагруженных) во вторую очередь. Забавно то, что куча народа готовы поливать грязью php, но написать про его реальные недостатки оказывается слабо (видать, дело не в недостатках php).

ну и цитаток:

быдлокод пишут быдлокодеры (быдлостудентики за быдлоеду)
красивый код можно писать на php равно как на python или java

Да-да-да.
А еще можно на руках быстро бегать, да.

Минусуем-минусуем. Между прочим прогеров питонистов, которые знают PHP очень много.
Обратного не наблюдается. Интересно почему...

К сожалению у PHP нету ни одного преимущества перед питоном (рад был бы конструктивной критике), а вот того что не поддерживает PHP немерянно.

Валяйте, внимаем

1. отстутсвие в PHP объектного подхода («всё есть объект»)

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

следовательно операция:


// PHP
require_once dirname(__FILE__).'/my_module1.php';
require_once dirname(__FILE__).'/my_module2.php';
require_once dirname(__FILE__).'/my_module3.php';
require_once dirname(__FILE__).'/my_module4.php';




импортирует НЕПОНЯТНО ЧТО

в отличии от


# python
import my_module1, my_module2
from my_module3 import my_super_class
from my_module4 import my_mega_class as mmc




и теперь когда (в python) мы используем my_super_class(...) , то мы чётко понимаем что это объект класса из my_module3, а не хрен пойми откуда

(тоесть легко читать чужой код)

зато в PHP — если назвать функцию именем длинной в 40 символов — то тоже будет ясно что это за функция и откуда она импортирована :-D :-D :-D

наверно именно по этой причине имена функций и классов в PHP охренительно длинных размеров... «htmlspecialchars» — это сума надо сойти пока такое написать :-) ... или вот mysql_real_escape_string ... ппц-просто

А такая вещь как пространства имен?
//PHP
//Хоть обназывайся
use My\Full\Classname as Another;
http://php.net/manual/en/language.namespaces.importing.php

php-5.3 — немного улучшает ситуацию...

правда — с теми символами которые не захотели обзавестись собственными namespace — остаётся всё таже жопа

...а не хотят обзаводиться namespace`ами ВСЕ модули... так как хотят тянуть за собой совместимость с PHP<=5.2


при этом остаётся неясным — зачем мучиться с PHP-5.3 в котором кучу говнофункций с PHP-5.2-семантикой...

...если можно просто взять и использовать удобный python :-)
(удобный для функционального стиля)

при этом PHP-5.3-семантика хоть и лишена части своих проблемм — но сёравно кое в чём вызывает отвращения... хотябы например этот способ записи пространств имён «\».. :-)

Валяйте, внимаем

2. трудность в использовании в PHP написание кода в качестве callback-функций

документация об http://ru2.php.net/manual/en/language.pseudo-types.php#langu... [ http://j.mp/eoEuQx ] даёт нам чотко понять,
что для того чтобы использовать в PHP функциональный подход — нужно каждый раз писать неслаженный код (с идиотскими названиями идентификаторов)

...например придётся написать не малый абзац кода для задействования операции preg_replace_callback()

тем самым PHP-программисты стараются не использовать функциональный подход в своём программировании... и тем сымым ухудшают качество получаемого кода (принцип DRY («Don't repeat yourself») плохо соблюдается, если избегать функциональный подход)

многие PHP-программисты вкушая неудовольствие от невозможности нормального использования функционального подхода — начинают использовать eval-хаки...

...в то время как python — весь так и блешшет функциональностью...

даже взять хотябы:


# python
my_obj = MyClass()
func = my_obj.my_method
a = func(b)

ну и цитаток 2:

Вы несете БРЕД
http://php.net/manual/en/functions.anonymous.php

это PHP-5.3 — которого нет на 99% хостингов

...
при этом параметр use($var1, $var2, ...) — просит указывать ВРУЧНУЮ все внешние переменные которые мне понадобятсья внутри такой анонимной функции — идиотская задумка — так как лешает половину прелестей самого понятия «замыкания»

а если у меня анонимная функция внутри анонимной функции — то придётся одну и туже переменную прописывать в двух разных use(...) — бред в квадрате :-)

Валяйте, внимаем

3. отсутствие в PHP — итераторов/генераторов

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

при этом — (как обычно) страдает принцип DRY.. так как из-за отсутствия генераторав-итераций — приходиться идни и теже обрабатывающщие части PHP-программы присать несколько раз (но с небольшими изменениями относительно друг друга)

выше в пункте {1} уже писалось про громадные названия PHP-функций..

громадные_названия плюс куча_избыточного_кода — приводят к тому что код плохо читается (например для нового программиста, того кто пытается разобраться в коде)

3. отсутствие в PHP — итераторов/генераторов

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

генераторы/итераторы в PHP — это пародия на генераторы/итераторы в Python. :-)

(название совпадает — но использовать ЭТО в PHP — никакого желания ни у кого даже не возникнет :))

а вот того что не поддерживает PHP немерянно

Валяйте, внимаем

NN. а это нищебродность массивов (в PHP)

например если я в Python пишу:


# python
x1 = my_array.get('x1', 'отсутствиющая фигня')
x2 = my_array.get('x2') or 'не пустая фигня'



то для PHP этот ОЧЕНь РАСПРОСТРАНЁННЫЙ случай придётся записать через:


x1 = array_key_exists('x1' $my_array)?$my_array['x1']:'отсутствиющая фигня';
x2 = array_key_exists('x2' $my_array) && $my_array['x2']?$my_array['x2']:'не пустая фигня';
// ------------------------------
// следущий код НЕ верен, так как вызывает ошибку в режиме «показывать все ошибки»:
// x2 = $my_array['x2'] or 'не пустая фигня'



чуствуюте разнифу в количество буковок кода?

при этом возникает желание в PHP написать свою собственную функцию «get()» (такуюже как в python dict.get()) — но в случае PHP<=5.2 придётся задавать для этой функции мега длинное имя... и тогда половина смысл этого нововведения теряется :-(

при этом как [я уже говорил] — зачем делать какието извращения в PHP — если можно всё сделать элегантно без извращений в python :-)

ну и цитаток 3 «возвращение цитатока»:

$x1 = @$my_array['x1'] ? $my_array['x1'] : 'пусто';
или совсем красиво
$x1 = @$my_array['x1'] or $x1 = 'пусто';

Юзать оператор подавления ошибок - предсмертная агония.

Кроме того, что это может породить множество ошибок, это просто адски неэлегантно.

Ну и просто посмотрите на питоновый код и на пхп. Какой из них понятнее ?

Но это на самом деле все фигня. Во первых это не списки а словари (только в пхп их почему то называют аасоцианивными массивами >_<). Во вторых тут никакой магии нет, это скорее в пхп нет очевидной операции.


Достаточно с вас и того, что питон язык со строгой типизацией.
Да, - динамической, но строгой.
Умному - достаточно.

В пхп вобще самая левая типизация, из всех что я видел.

это точно!

чего стоит только:


$str = '0'; // строка в которой символ нуля (тоесть строка не пустая)

if($str) {
echo 'этот вариант былбы в любом нормальном языке, но не PHP';
} else {
echo 'PHP щитает что строка всётаки пустая'; // :-)
// это потомушто '0' (строка) похожа на 0 (число) ??? %) %)
}

// ...

$str1 = '00'; // тоже самое, но символов нуля уже два

if($str1) {
echo 'о да! на этот раз строка уже не пустая, даже для PHP'; // :-) :-)
}



интересная такая типизация, просто вообще :-D

а вот того что не поддерживает PHP немерянно

Валяйте, внимаем

Ну давайте.

Начнем.

1) Отсуствие каого-либо ФП: функций высшего порядка, map-ов, замыканий, работы со списками и многого другого.

2) Нет нормальной работы со списками. Та порнография, что представлена в пхп не считается. Срезы, лист/генератор компликэйшен, map, отрицательные индексы...

3) Кривая типизация. Ну это уже освещали...

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

5) ООП. В пхп его нет. Это не ООП. PHP не поддерживает даже базовых конструкций, тем более чисто питоновских (propery, динамическое изменение полей, динамическое представление полей...)

6) Интеграция с C. Можно делать высоковоспроизводительные либы. SciPy к примеру.

7) Сообщество. Да, у PHP больше сообщество, но по качеству его не сравнить. У питонистов ПРИНЯТО писать хороший код, а обыччно есть даже нормальная дока у библиотек. Нормально написанные PHP приложения, днем с огнем не сыскать.

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

Ерунду написал. Ответ-то на самом деле прост: у питона нет своей ниши
- как язык общего назначения он бесполезен, как веб-язык - проигрывает
php, несмотря на все свои интересные особенности, благодаря которым как раз
и проигрывает (потому что они никому здравомыслящему не нужны, т.е. все
плюсы питона являются плюсами только для его поклонников). Хотя скорее так:
он не проигрывает php, он просто не имеет никаких таких преимуществ
перед php, чтобы при выборе между ним и php выглядеть действительно
более предпочтительным.

Ненадо тут пожалуйста.

Питон это не хаскель и не лисп (ничего против не имею (: ), в питоне все фичи заточены на чисто практическое использование (почитайте Гвидо например, я кстати с этой политикой практичности несогласен).

Даже в небольшом проекте используются практически все названные фичи.

Преимуществ у питона в вебе море. Веб фреймворк на питоне это не возможность пэйстом вставлять ХТМЛ элементы и работать с БД на чистом SQL. Веб-фреймворки дают удобные средства для этого. За один толко питоновый ORM Mapper, пхп можно зарывать.

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

В общем, очень бы хотелось, что-бы вы ознакомились с сабжем, потому-что по вашим комментариям кажется что вы с питоном знакомы на уровне «есть такая штука». Почитайте статьи о списках в питоне на хабре и/или доку Django или Pylons.

Очень хотелось бы услышать реальный конструктив (:

Между прочим прогеров питонистов, которые знают PHP очень много.
Обратного не наблюдается. Интересно почему...

+Миллион!

Делаю веб-сервисы на протяжении уже почти 10 лет. Начинал с PHP, сейчас работаю только с питоном, во фреймворке Django. PHP объективно устарел.

Помимо всех тех блестящих преимуществ Django, о которых и так везде написано, хочу отметить ещё одно, которое упоминается не так часто: поскольку Django это фреймворк относительно молодой, вокруг него сформировалось сообщество умных, высококлассных программистов. Взаимодействовать с авторами сторонних библиотек — одно удовольствие!

Думаю, что со временем, когда PHP начнёт терять популярность, кол-во дерьмового кода(и дерьмовых программистов) на питоне сильно возрастёт.

Сейчас PHP это магнит быдлокода, он защищает Питон также, как Юпитер защищает Землю от пролетающих метеоритов.

Девочки любят, когда на руках ходят, а до красивого кода разница только
тем, кто его читает, разве нет?

Оооу. Как все запущено...

Вот по этому принципу и пишется большинство PHP приложений. Написал и выбросил.

Все правильно сказад, нужно писать на ЖАБА, посмотрите на HTML код любой страницы лора Ж

В bottle.py можно дёргать этот запрос только тогда, когда нужно, и держать его всё время в памяти - новое обращение может сразу посмотреть «а что у нас в памяти», а не дёргать заново. bottle.py не умирает после запроса, а продолжает работать всё время.

Ты, похоже, описал php cache (APC, eaccelerator, zend и другие). Кроме того, такая техника перестает работать в распределенной системе, так кеш должен быть доступен для всех фронтэндов. Так что в php это есть.

P.S. Если ты так озабочен скоростью работы, посмотри на CAS (C++ Application Server). http://cas.havoc.ru/

Если ты так озабочен скоростью работы, посмотри на CAS (C++ Application Server).

тебя бросает из стороны в сторону как неокрепшего подростка...

сказали же тебе: php - устарел, php - ржавчина; есть более хорошо продуманные и более спелые сочные инструменты.

не хочешь понимать - не понимай.

конечно, всегда был есть и будет ruby.

по сравнению с php, даже ruby выглядит не плохо

Ты, похоже, описал php cache (APC, eaccelerator, zend и другие).

Я специально написал про memcached. Всё равно, при каждом запросе всё окружение выстраивается заново.

P.S. Если ты так озабочен скоростью работы, посмотри на CAS (C++ Application Server).

У python хватает разных библиотек, на разных языках. А по скорости отдачи - смотри заглавное сообщение темы.

P.S. Если ты так озабочен скоростью работы

Если что, я раньше тоже писал свой сервер, который сам и обрабатывал всё. Было быстро и привычно. Но bottle.py даёт несравненно больше.

На php я писал с 2002 года. И мне хватает причин, чтобы им пользоваться только в самых редких случаях.

по сравнению с php, даже ruby выглядит не плохо

Что шаблоны, что роуты в рельсах - не самое приятное занятие для новичка. Sinatra тоже не особо лучше. Поэтому bottle.py выглядит предпочтительнее.

Или это плохо?

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

А аналог от php есть?

Аналог вот такого??
c.execute(«SELECT id, task FROM todo WHERE status LIKE '1'»)

Спасибо, но от такой практики я начал стараться избавляться без малого 10 лет назад. И лет 6 назад от неё избавился. Снова возвращаться к этому — увольте :D

Это если у них разные ORM и шаблонизаторы будут.
А использовать можно любой. И тоже можно провести тесты.
Например самый быстрый из известных шаблонизаторов - http://www.cheetahtemplate.org/. Его можно к любому фрэймворку прикрутить.

Это если у них разные ORM и шаблонизаторы будут

Ну а как без них в серьёзном проекте?

А использовать можно любой. И тоже можно провести тесты.

Ну так, вот с этой точки зрения вопрос и интересует. А то, помнится, пару лет назад был большой тест одного товарища по этой теме, так оказалось, что Django на практических задачах работает в итоге примерно с той же скоростью, что и symfony на php с акселератором. Правда, с тех пор и тот, и другой фреймворк сильно развились, так что х.з., как оно сегодня обстоит.

Ну так, вот с этой точки зрения вопрос и интересует.

В таком виде мне тоже интересны тесты, но времени пока нет.

Конечно, лучше для новичков парсить строку, получая инъекцию в чистом виде.

А для старичков - проблем с ORM в python нет. Только я вот что скажу - большинство проектов не используют ORM, а парсят строку. И поэтому они регулярные гости раздела security в позиции sql-injection.

так оказалось, что Django на практических задачах работает в итоге примерно с той же скоростью, что и symfony на php с акселератором.

Во-первых, с каким именно акселлератором. А во-вторых, то, что Django пешком проиграл php на машине, говорит только о неверном сравнении, и ни о чём другом.

В таком виде мне тоже интересны тесты, но времени пока нет.

В python-процессах данные можно держать всё время. Так что тебя разводят на неверное сравнение.

В python-процессах данные можно держать всё время.

Угу. Хотя бы все 5Гб непарсеного текста форума ЛОРа? :)

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

Так что тут надо или трусы снять, или крестик надеть. А сферические кони в вакууме — это другой отдел.

Понимаю. Не понимаю почему такой акцент на это.... Это даже хорошо.

Только он неблокирующий. Это Скайп неблокируемый.

У bottle.py нет запросов к бд из коробки, если не считать sqlite-plugin в новых версиях.

И не надо. Зачем мне запросы к БД как в джанго например? У мня в одном проекте MS SQL. В другом вообще нет СУБД (все в XML). В третьем CouchDB.

Вот и нафига мне Django ORM?

Вычисление N знаков числа Пи?

Сервер для 1С который печатает на кассовом аппарате. Он отдает состояние ККМ и по POST запросам печатает чеки.

И БД БД рознь. У меня часто ZODB есть.

У меня случай с интернет магазином. Так вот постгрес отдавал данные в три раза быстрее чем их рендерил шаблонизатор.

мне в пхп на фоне того ж питона не понравились:
1) $ в названиях переменных
2) громоздкие конструкции для простых вещей. то есть там где в питоне можно сделать str[3:] в пыхе приходится какую-то ф-ю пользовать

Ну ты даешь, на 2 страницы расписал какой убогий php и какой суперский python !!! Мы это знаем! И что дальше. А дальше приходит криворукий вебмастер , таких сейчас развилось тысячи и хочет склепать сайтик клиенту или себе и что он сделает - правильно, он выберет одну с cms написанных на убогом php Я к чему это говорю,при всем удобстве использования python в вебе на нем реально мало готовых из коробки к употреблению cms с разной функциональностью. Я вот , например не встречала ни одной коммерческой cms на питоне. Правда сейчас начал появляться клон cms основанных на django. Итог, вместо того чтобы разводить холивар может лучше начать создавать удобные продукты на замечательном и всеми любимом python

А вы пробовали развернуть проект на питоне? Ну например вы создали сайт на питоне и вам нужно его разместить на виртуальном хостинге. Вот тут то и начинаются проблемы. Да я безусловно со своим опытом могу развернуть любой проект на питоне, даже если на хостинге python поддерживается через жопу(cgi) так вот при всем убогости пыхпыха у него есть одно важное преимущество перед питоном в вебе - проекты и сайты написанные на пхп легко развертываются практически на любом хостинге

Вот вам пример из моей практике только вчера, хостинг -timeweb заявлена поддержка python (через wsgi) и django, причем джанго может установить автоматически из панели управления хостингом , я поленилась развертывать виртуальное окружение и воспользовалась тем что есть в итоге обнаружила что на хостинге нет PIL . А это значит что хостер даже не понмает что если он завляет поддержку django он должен удосужиться поставить PIL как минимум

А зачем вообще пользоваться чем-то отличным от VPS|Облака|Dedicated? Первые два уже давно очень дешевы и никаких проблем со средой - настраивай сколько влезет. Не хочешь настраивать - apt-get install настроит по умолчанию.

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

Не посоветуете простенькую CMS на php? Интересен личный опыт, обзоры вида «Top 10 lightweight CMS» читал, но кроме путаницы они ничего нового мне не принесли.

А зачем вообще пользоваться чем-то отличным от VPS|Облака|Dedicated?

есть ряд заказчиков, которым 10 баксов в месяц за хостинг пары страниц с координатами их конторы это дорого, а вот по 5 самое оно :(

приходится компоновать таких кучкой на VPS если им не принципиально на кого хостинг куплен

это ниша статики и joomla с компанией, мне решительно не понятно зачем нужно программировать на такой задаче

И чо? Всё равно на реальном проекте запросы к базе сведут на нет всю эту «скорость». А вообще есть такая вещь как кэширование.

P.S. Ну почему, почему все люто фапают на «скорость» при веб-разработке?

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

Так вот постгрес отдавал данные в три раза быстрее чем их рендерил шаблонизатор.

А теперь читаем тему сначала :)

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

Нет вряд ли что посоветую на php. Уже года три с ним не работаю. Клиентам даже не сложные сайты разворачиваю на django, django-cms, у меня давно обкатанные решения есть на разные случаи от сайта визитки до портала и интернет магазина. Нестандартный функционал дописываю. Сейчас правда пишу проект на Werkzeug

я там про программирование ничего не писал, о чём вы? мы обсуждали хостинг

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

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

Я к тому, что нормальный фреймворк не привязывает тебя к шаблонизатору и ОРМ. Поэтому человек тестирует на нагрузку 1 часть из системы, а именно web отдавалку.... А потом можно рассуждать о скоростях ОРМ или шаблонизаторов в отрыве от web.

Разве это не разумно? А потом из лучших попробовать собрать комплект

то написанное на пхп развертывать легче чем написанное на питоне

О майн гот. Я заливаю 1 архив по ssh копирую в init.d запускалку и в nginix сайт. Что сложного?

ну да друпал можно, там функционал на все случаи жизни, только под капот не заглядывай, ужасней кода я встречала))

о множесте виртуальных хостингов на пыхе речь

Год назад еще у PHP было преимущество в количестве хостинга. Теперь VDS за 150 рублей позволяет хоть хаскели хостить пачками

Стоп, я сама для клиентов часто использую VDS. Речь не об этом, во первых VDS еще надо настроить это время и знания. Мы же говорим почему популярен в вебе пыхпых. В большинстве случае пхп программист сиди в винде и для него зайти через ssh часто нетривиальная задача, я уж не говорю о том что нужно еще и разбираться в командной оболочке. Вот о чем у нас речь.

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

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

Я к тому, что нормальный фреймворк не привязывает тебя к шаблонизатору и ОРМ

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

Что толку тестировать сервер, если всё уткнётся в источник данных и обработку.

Яркий пример случая преждевременной оптимизации.

А потом из лучших попробовать собрать комплект

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

А потом можно рассуждать о скоростях ОРМ или шаблонизаторов в отрыве от web.

Только демагогии ради.

Согласна так я и делаю у меня есть скрипт который я написала на питоне и который настраивает VPS на Debian или Ubuntu, устанавливая нужные пакеты и конфиги. Но опять же я к этому пришла через опыт настройки вручную, пхп программисту это не нужно он забросил на сервер скрипт зашел в установщик этого скрипта install.php и он в шоколаде))) Чтобы питон стал массовым на серверах python программистам надо делать удобные инструменты которые облегчат развертывание программных продуктов на python на серверах