Дочитал Defending Pyramid’s Design. Статья описывает, почему в Пирамиде сделали так или иначе определенные вещи.

Особенно доставило http://docs.pylonshq.com/pyramid/dev/designdefense.html#microframeworks-have-smaller-hello-world-programs
Подробно разбираются популярные грабли bottle и flask с разъяснением, почему никогда не стоит использовать такой дизайн.
Наглядно и доходчиво.

Рекомендую. Читать от ссылки и до конца файла.
Определенно, мне эти ребята нравятся все больше и больше.

Андрей Светлов, сейчас им фактически удалось то, чего добивались bfg и grok =) - снизить порог вхождения в фреймворк, который базируется на ZCA, и скрыть эту самую ZCA для непосвященных =). Что здесь может не нравиться?

ZCA - это понятно.
Я о другом.

1. Почему нельзя настраивать конфигурацию при импорте модуля?
2. Почему правила роутинга нужно писать в одном месте, не разбрасывая их по всему коду?
3. Почему глобальные переменные (даже весьма хитрые, с threadlocal) - зло? Этот пункт для совсем деревянных.
4. Отчего wsgi app должно быть именно приложением и не должно пытаться запустить весь wsgi stack с какими-то настройками по умолчанию?

По опыту знаю, первые два пункта особенно неочевидны.

А чем “микро” отличается от простого?

Zubchick
А чем “микро” отличается от простого?

мне, на самом деле, сложно объяснить, но, походу, в понимании общественности - чем меньше в фрейморке “batteries included”, тем больше он “микро”. Как-то так …

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

Андрей Светлов
Подробно разбираются популярные грабли bottle и flask с разъяснением, почему никогда не стоит использовать такой дизайн.
Наглядно и доходчиво.

прочитал. я так понял что они говорят, что создание роутов через декораторы - плохо, т.к. они дублируются.
они не дублируются если запускать приложение правильно - нельзя импортировать запускаемый файл, т.е. если создать файл start.py:
то их “некорректный” пример работает корректно.

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

1. Порядок имеет значение - таблица роутов применяется последовательно, до первого совпадения.
2. Эти модули могут циклически импортировать друг друга. Это, конечно, неправильно.
Но в некоторых случаях (нет import .. from ..) питон ошибку не выдаст - а код модуля исполнится несколько раз.
А потом (может, и через месяц-другой) после очередного изменения все ломается.
Я такое видел на наших проектах. И, хоть и ни разу был не Веб - найти ошибку было нелегко.
Тоже обвешивали разными сомнительными декораторами.
Когда проект большой, это случается.
По хорошему за такое бьют по рукам - но мир не идеален.
В результате пришли к чему-то, напоминающему декораторы вьюшек в пирамиде. Декоратор только добавляет атрибуты - а конфигуратор уже потом их анализирует.

Так что и пример некорректный, и ситуация вполне жизненная.
Нечастая, да. Но каждый раз это отлична порция геморроя.

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

Это не глюк - просто фича.
Оборотная сторона очень мощной особенности - импортируемый код исполняется.
Фича проявляется, когда змеюку начинают бодро хватать за хвост.
До какого-то момента она терпит. А потом начинает кусаться.

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

При этом bottle и flask отлично работают, если весь код помещается именно в один файл.
Дальше нужно внимательно смотреть.