Посоветуйте модули/технологии python для реализации простой ИС.

1) flask 2) MySQL

1. Django, Pyramid, bottle, etc
2. Без разницы, я бы взял постгрес.

1. Django, Pyramid, bottle, etc 2. Без разницы, я бы взял постгрес.

Django слишком жирно. Мне чем проще, тем лучше. Желательно вообще без фреймворков...

Желательно вообще без фреймворков

Велосипедо-строитель?

P.S. Используй web.py, pyramid, flask, bottle или django, как тебе люди советуют.

Django слишком жирно.

Да че там жирного, прототип вообще за вечер набросаешь.
Плюс админка сразу готовая.
А вот без фрэймворков такое писать замучаешься. Чувствуется PHP-подход.

Чувствуется PHP-подход.

php-подход это как раз Django. 100500 модулей, как у всяких LiveStreet и убогая ORM, для которой разработчики советуют использовать RAW SQL.

PHP подход в том плане, что каждый веб кодер пишет свою cms-ку чуть ли не под каждую задачу. Если не хватает Django-orm (как мне подсказывает опыт - просто не умеют пользоваться) - ну юзайте pyramid и sql-alchemy.

PHP подход в том плане, что каждый веб кодер пишет свою cms-ку чуть ли не под каждую задачу.

о да, я как-то делал админку на Django. Чтобы добавить еще один inline там нужно писать кучу костылей. Расширение шаблонов с хаками, вроде /admin/foo.html с исправление одного куска и /admin/foo/foo.html с исправлением куска в /admin/foo.html. Content type - вообще помойка, пользователи хоть и с сольную, но зачем-то используется md5 и sha256. Можно было бы обойтись одним sha256 и не писать всякую чушь в БД. Сессии в БД - pickle объект с какими-то костылями. beaker в разы удобнее и гибче.

Если не хватает Django-orm (как мне подсказывает опыт - просто не умеют пользоваться)

это как раз вопрос к content type. Я тут выкладывал примеры костылей, где выбирались данные из самих таблиц, а потом через одно место фильтровались через content type, который тоже занимает один SQL запрос.

ну юзайте pyramid и sql-alchemy

а зачем вообще советовать Django, если оно приведет к костылям, как в php CMS?

Желательно вообще без фреймворков

Велосипедо-строитель?

P.S. Используй web.py, pyramid, flask, bottle или django, как тебе люди советуют.

Моя цель прежде всего научиться. Поэтому нужно как можно проще.

Посмотрел один проект — Ajenti. Но не совсем понятно как там сделан web-интерфейс...

а зачем вообще советовать Django, если оно приведет к костылям, как в php CMS?

Я конечно не профессиональный програмист, но у меня ни разу к костылям это не приводило. Правда и сложные системы на Django я не писал.

Моя цель прежде всего научиться.

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

Поэтому нужно как можно проще.

Если нужно проще, используй любой фреймворк из перечисленных выше: web.py - самый минималистичный, пожалуй; flask и bottle - гибки и элегантны; pyramid и django - просты и удобны для 90% задач. Если нужен php-way, то пиши дырявый велосипед, но это точно будет не python-way.

Если нужно проще, используй любой фреймворк из перечисленных выше: web.py - самый минималистичный, пожалуй; flask и bottle - гибки и элегантны; pyramid и django - просты и удобны для 90% задач. Если нужен php-way, то пиши дырявый велосипед, но это точно будет не python-way.

Ну почему же не python-way? Ajenti написан на python, но в нем не используется никаких фреймворков. Вот эту простоту я имею ввиду.

Ну почему же не python-way?

Потому, что идеология питона (в PHP, к примеру, сложилось наоборот) подразумевает минимализацию необходимости в лишних телодвижениях и написании велосипедов. Обычно новое решение базируется на чем-то готовом и хорошо отлаженном, а не написанном вчера на коленке. И только в случае крайней необходимости пишется свой велосипед, но уже тогда, когда становится понятно, что остальные решения не обладают необходимой гибкостью и написать свое с нуля - менее затратно. Такое решение не принимается с бухты-барахты, а базируется на тщательном исследовании готовых вариантов и их достоинств/недостатков по отношению к реализовываемому проекту. А желание написать с нуля только потому, что готовое решение написано кем-то другим - это уже так называемый синдром NIH.

обычно новое решение базируется на чем-то готовом и хорошо отлаженном, а не написанном вчера на коленке.

Ой не верю я вам, не верю. Все хорошо сделанные проекты (вот недавно вдруг узнал, пообщавшись на конференции, что я один из немногих, кто вообще видел нормально реализованные проекты), которые я видел, использовали из готового только базовые вещи (библиотеки доступа к БД, веб-серверы, шаблонизаторы и так далее). Любой серьезный проект на крутом фреймворки - куча говнокода , одни костыли и подпорки. Вот бери любое рельсовое приложение и выкидывай на помойку. Все круто, переиспользование и все такое. Только вот код - говно. Мое объяснение ситуации такое: приложения обычно представляют собой очень и очень конкретные вещи, для которых очень сложно сделать общее, переиспользуемое решение. Вот всякие базовые вещи как раз очень даже общие, потому и переиспользуемые. Заметьте, я не выступаю за написание своих фреймворков и CMS-ок, я вообще против их использования. Программисты любят строить воздушные замки (или заниматься использованием чужих), хотя в большинстве случаев нужно просто по-быстрому закодить частное решение, делов-то.

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

Ну так пиши админку руками как в любых других фреймворках.

так а зачем тогда Django советовать?

Ой не верю я вам, не верю.

Вы ведь понимаете, что у каждого свой опыт, верно? Работая в очень крупной конторе, мы всегда использовали по максимуму готовые наработки, как свои собственные, так и сторонние. Вопрос о написании чего-то своего с нуля, без использования готовых решений никогда не поднимался, практически (за редкими исключениями, когда подходящих решений просто не было, либо их минусы перевешивали все риски написания с нуля), ибо дороже было пилить свой велосипед на несколько тысячк строк, на который поначалу даже не будет документации нормальной. И никто не гарантирует, что спроектированная архитектура будет идеальной (если вы не Линус конечно ;) и не упрется в какое-либо серьезное ограничение.

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

Ну не может один человек быть оркестром, хоть убейте. Сделать все лучше, чем другие люди, специализирующиеся в конкретной области, никак не получится, иначе придется потратить уйму времени. Какой заказчик согласится вам его оплачивать? Или вы из своего кармана будете брать деньги? Где оценка рисков? А они будут очень высоки при написании с нуля. Как я уже писал выше, в 90% подходят готовые решения. Да, бывают те 10%, когда приходится делать что-то совсем свое (и у меня такое бывало), но это именно в 10% случаев, а не во всех 100%.

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

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

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

1) web.py
2) sqlalchemy

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

Мое объяснение ситуации такое: приложения обычно представляют собой очень и очень конкретные вещи, для которых очень сложно сделать общее, переиспользуемое решение. Вот всякие базовые вещи как раз очень даже общие, потому и переиспользуемые. Заметьте, я не выступаю за написание своих фреймворков и CMS-ок, я вообще против их использования. Программисты любят строить воздушные замки (или заниматься использованием чужих), хотя в большинстве случаев нужно просто по-быстрому закодить частное решение, делов-то.

Абсолютно согласен.

Сделать все лучше, чем другие люди, специализирующиеся в конкретной области, никак не получится, иначе придется потратить уйму времени. Какой заказчик согласится вам его оплачивать?

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

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

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

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

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

Нужно решать задачу, а не строить воздушные замки.

Согласен )

то это как раз те 10%, для которых необходимо разрабатывать с нуля.

Я не ВЦИОМ, но возможно масштабы трагедии сильно больше, чем 10%. Недавно общался с одним питонщиком. Он расказывал, как перешел с Django на Flask, и наконец глотнул свежего воздуха, делая админку по-быстрому на коленке ручками, а не мучаясь кастомизируя джанговскую. Чел достаточно грамотный спец. А сайтец он делал довольно простой. Если на таких простых случаях абстракции текут...

Он расказывал, как перешел с Django на Flask, и наконец глотнул свежего воздуха

Ну, flask конечно гораздо более гибок, продуман и приятен, поэтому не стоит удивляться.

А сайтец он делал довольно простой. Если на таких простых случаях абстракции текут...

Если брать наш опыт, то практически все веб-продукты (некоторые имеют посещаемость 10к-30к уников в сутки) были сделаны на Django в качестве бэкэнда, проблем с допиливанием админки, не совместимых с жизнью, не наблюдалось. Зато любой разработчик, пришедший в команду, сразу мог влиться в процесс разработки без переучивания, а это огромный плюс, как и большое количество how-to и отличная документация Django. Так что все зависит от конкретного случая конечно же.

если у тебя простой веб-интерфейс в духе «привет из двухтысячных» то bottle.py, flask. Если у тебя интерфейс на ajax то... в этом случае выбор фреймворка играет ещё меньше т.к. основной код будет в .js, а не в питонячих скриптах.

MySQL либо PostgreSQL. Что посоветуете?

mysql т.к. он проще. postgres тяжелее в освоении, но «идеологически более правильный sql». А вообще, если база маленькая, то sqlite :)

Да, кстати, «простую информационную систему для работы внутри сети» ни о чём не говорит. Может тебе нужна тупо вики.

+1, о джанге даже не вспоминаю. В джанге всё гвоздями прибито. У меня часто возникали ситуации когда было проще что-то с нуля написать чем допиливать встроенные джанго-батарейки.

Сам пишу подобный «хелловорлд», только на PHP.
2. У меня Постгресс, просто потому что его лучше знаю. НА таких объёмах и задачах марка БД не принципиальна. 3. Дык какие тут примеры, все кубики есть, просто собрать их. Как лего ))

если у тебя простой веб-интерфейс в духе «привет из двухтысячных» то bottle.py, flask. Если у тебя интерфейс на ajax то... в этом случае выбор фреймворка играет ещё меньше т.к. основной код будет в .js, а не в питонячих скриптах.

Интерфейс хотелось бы сделать наподобие как в ajenti. Там вроде бы ajax. Только вот вопрос — как связать код питона с js? Какие библиотеки лучше для этого использовать? Есть ли какие-то мануалы в сети?

Да, кстати, «простую информационную систему для работы внутри сети» ни о чём не говорит. Может тебе нужна тупо вики.

Это будет учетная система.

Это будет учетная система.

О! 1С
XD

Не вариант

flask + PostgreSQL /thread

как связать код питона с js?

через json, наверно. На стороне питона просто отдаёшь dict и list, а фреймворк (bottle, flask, etc) сам сериализует в json.

Это моё видение, но я не спец в веб-технологиях.

100500 модулей, как у всяких LiveStreet

LiveStreet — это нишевое решение, ориентировано на построение блогосервисов. Но со своими задачами оно справляется на ура.

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

Ух ты! Вот, оказывается, как называется та хрень, которой я болен.

если у тебя простой веб-интерфейс в духе «привет из двухтысячных» то bottle.py, flask. Если у тебя интерфейс на ajax то... в этом случае выбор фреймворка играет ещё меньше т.к. основной код будет в .js, а не в питонячих скриптах.

Я так и не понял как фронтовый интерфейс может быть завязан на бэкэнд. Да какой бы он ни был - вещи не связанные совсем.

Логика сайта может обрабатываться как на стороне сервера, так на стороне клиента.

Логика сайта может обрабатываться как на стороне сервера, так на стороне клиента.

Это я как бы знаю, потому уже несколько лет как веб-разработчик )

Я не понял как может простота/сложность интерфейса быть завязана на бэкэнд. Аякс-не-аякс, девяностые-не-девяностые - на бэкэнд это не влияет ну совсем.

на бэкэнд это не влияет ну совсем.

смотря чем бэкенд занимается. Если убрать с него задачу рендеринга темплейтов итд итп то он может сильно упроститься.

Что такое джанга? orm, темплейты, всякие батарейки. Вот большинство батареек типа движок комментариев, все навороты с темплейтами итп просто будут не нужны.

Остаётся midleware, orm, авторизация... Тривиальные вещи которые или самому не сложно написать или они уже везде есть. Поэтому я и говорю что не влияет. Моё ламерское имхо.

Ну, темплейты и ORM это как раз самое вкусное. Зачем превращать все в PHP, отказываясь от шаблонизатора и напрямую завязываясь на конкретную базу?

А если использовать jinja в качестве шаблонизатора, то вообще без разницы будет что в бэкэнде: flask или django.

LiveStreet — это нишевое решение, ориентировано на построение блогосервисов. Но со своими задачами оно справляется на ура.

я готов принести в жертву девственицу за то, что мне больше не нужно работать с php и LiveStreet. Он клал сервер уже при 2к обращений в сутки, а со всякими кэшами максимум 10к человек.

Лол, пусть напишет что-нибудь ~30LoC на фласке.

Клал сервер при одном запросе в 40 секунд? Прохладная история.

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

Менеджмент ассетов, если у нас все на клиенте, можно обойтись и башем.

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

Авторизация через фейсбуки, можно написать руками.

Отправка емейлов, можно написать руками.

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

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

Как только увижу такое на фласк сразу поверю.

Клал сервер при одном запросе в 40 секунд? Прохладная история.

достаточно залочить таблицу и весь LiveStreet встанет. Пример запросов можно увидеть, включив sql slow query low.

Он клал сервер уже при 2к обращений в сутки

Есть проект, держащий более 70к в сутки. Правда, он сильно переписан, но в основе его LS.

достаточно залочить таблицу и весь LiveStreet встанет

Это проблемы MySQL, нет?