Валерий Семенов

Навскидку — traversal, встроенный контроль доступа, регистрация view-функций значительно богаче(могу ошибаться), заменяемые рендереры, asset overriding(хотя, я так и не понял, зачем).

Они развиваются немного в разных направлениях. Для меня привычнее Pyramid, т.к. он вышел гораздо раньше. Хотя начинал я еще с Pylons. Вот и вся разница.

> Что есть в pyramid, чего нет во flask?

ну и самый простой ответ на этот вопрос: если этого нет, то сделай сам. Они настолько минималистичны, что за сутки можно перенести что угодно. Я еще на Python 3 перешел и приходилось подправлять WebOb, PIL пилить, но потом нашел менее кривой пакет.

Насчёт сессий, если будете использовать какой то framework посмотрите не реализованная ли для него обёртка для SQLAlchemy.
Например разработчики SQLAlchemy, рекомендуют использовать для Flask — packages.python.org/Flask-SQLAlchemy/
для Zope & Pyramid — pypi.python.org/pypi/zope.sqlalchemy

Конфиги можно хранить в отдельном классе config.py

class Config:
    DEBUG = False
    POST_PER_PAGE = 20
    etc ......

Насчёт моделей тоже интересно, хотелось бы увидеть реализацию каждая модель в своём файлике, чтоб легче было сопровождать, а то обычно всё в одном файле и когда моделей много начинается ад. Я как то пробывал играться нарвался на cyclic import и плюнул.

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

А так, универсальный ответ — открываем доку, читаем, выполняем примеры…

Как вариант к перечисленному выше — деплоить из capistrano на два разных сервера.

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

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

Начиная с версии 1.3, в Джанге по умолчанию используется django.contrib.staticfiles — отличное приложение, упрощающее работу со статикой проекта.

В режиме разработки, то есть когда runserver запускаете, это приложение ловит все запросы, которые начинаются на STATIC_URL и ищет запрошенный файл без этого префикса в папке static каждого приложения в INSTALLED_APPS.

Не вдаваясь в подробности, которые прекрасно описаны в манулае, могу вот что посоветовать: сделайте приложение с именем, например, sitemedia, подключите его в INSTALLED_APPS, внутри этого приложения создайте директорию static и поскидайте всю статику туда.

Обратите внимание только: статику, а не медиа! Это разные директории для разных целей.

И ещё: в 1.4 ADMIN_MEDIA_PREFIX не используется.

Всем «переходящим» нужно в первую очередь читать PEP8 ( www.python.org/dev/peps/pep-0008/ )

Использую вот эту библу, русский язык ок. У меня везде юникод.

Вообще ассерты не для тестирования или проверки переменных, они больше для избавления от проверок. Ставите ассерт там где «не хотите проверять» код и забываете про него пока не увидете сообщение об ошибке. И ставятся они не там где вы знаете что будет ошибка, а там где _возможно может_ произойти ошибка, но не факт что вообще произойдет. Ассерты можно раскидать по таким местам и просто забыть про них до сообщения об ошибке. Они так же отключаются все глобально, поэтому можно не убирать из даже после выпуска проекта, а лишь отключать на живом.

А я ушел от PHP в армию. Вернулся Java программистом.

Поправлю Вас

Известно, что PHP программистов в наше время «великое множество»

PHP программистов, как и программистов в целом ничтожное меньшинство, великое множество малоопытных программят.

Как вы ушли от PHP?

Как вы думаете, что вам скажет музыкант в ответ на вопрос «Как бы бросили балалайку и начали играть исключительно на домре?» или у сантехника «Как вы перестали пользоваться ключем на 13?»
Нельзя прийти или уйти от языка — это инструмент, который предназначен для определенных задач. И хороший настоящий программист должен наращивать свой инструментарий, и уметь его использовать по назначению.

Если говорить именно о недостатках языка — то мне лично не нравится в нем нестрогая типизация и всякие неожиданности zend engine — как например интуитивно непонятная оптимизация работы со значениями по ссылке.

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

Паттерн этот называется ООП :) А именно — использование абстрактных классов и наследование. Советую почитать хорошую старую литературу типа Гради Буча.

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

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

возникла мысль написать архитектуру сущностей, как набор примитивных классов-параметров

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

Похоже это паттерн компоновщик, хотя я могу ошибаться.