Мега-Учебник Flask, Часть 11: Поддержка e-mail

[loststylus]

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

[merlin-vrn]

А сама по себе отправка емейла — и есть процесс передачи задачи в очередь. Процесс заключается в следующем: мы вызываем локальную доставку командой sendmail. Если это sendmail от достаточно продвинутого пакета (postfix, sendmail, exim), то он только и делает, что ставит сообщение в очередь для доставки и сразу же возвращается. А дальше уже сообщение подхватит другой демон, отвечающий за разбор этой очереди.

[pythonprogrammer]

Люди, работающие плотно с flask, подскажите, какие у него есть преимущества перед Django?
Я, изучив его доки, сделав свой 1 проект небольшой на нем и какое-то время поучаствовав в разработке чужого большого проекта — пока никаких не увидел.
Да, я знаю (с чужих слов), что SQLAlchemy пофичастее Django ORM, а Jinja2 побыстрее рендерит шаблоны, чем джанговский движок. Но, это не сам flask. А чем же flask-то лучше? Я вижу, что большинство внешних расширений для flask пытаются из него джангу сделать.
Так в чем же его достоинства все-таки?

[danSamara]

Не работаю с flask плотно, но отличия, на мой взгляд очевидны — он менее «связный». Django предоставляет хорошую основу для сайтостроительства, но он монолитен и смена какого-либо компонента может быть сопряжена несовместимостью с батарейками и вызывать глюки в ядре. Flask-же обезжирен по максимуму. А много расширений подгоняющие flask под django — это хорошо, есть из чего выбрать :)

[un1t]

Я Фласк активно сейчас не юзаю, и не могу сказать что освоил его вдоль и поперек, но несколько проектов на нем сделал. Для совсем небольших проектов, которые умещаются в один файл, удобно тем что можно действительно обойтись одним файлом, а у джанги будет целая куча файлов даже для hello world. А вот когда проект становиться большим, то у него уже появляется структура и он постепенно превращяется в Джангу, правда своеобразную Джангу, без батареек. Батарейки во фласке безусловно есть, но количества сравнимого с Джангой нету. Я сделал два проекта на Фласке, а когда они немного подрасли, плюнул и переписал на Джангу. Слишком много приходится писать велосипедов, которые в Джанге есть готовые.
Jinja2 прикольная и мне понравилась, но написание кастомных тэгов меня ужаснуло. Тут я тоже и итоге предпочел джанговские шаблоны, местами шаблоны конечно не так удобны, зато кастомные тэги пишутся на раз-два.

[CJay]

пишу на Flask. Он очень гибкий. Захотелось вместо SQLAlchemy выбрать peewee — используй, никто не против. Вместо Jinja2 захотелось Jade — пожалуйста. Хватает 1 файла? Пиши в нём. Хочешь дорасти до django — расти. Но не думаю, что кто-то пытается сделать из него django, или как-то противопоставляет их. Просто пишется нужный функционал, не удивительно, что он уже может быть реализован в django ранее.
В нём всё прозрачно. Нет никакой «магии».
Ну и чисто субъективно. Мне очень нравится маппить урлы декоратором @app.route("/services/", methods=["GET","POST"]) в файле с вьюхами, чем в отдельном urls.py писать:

urlpatterns = [ url(r'^services/$', views.services_list_view), ... ]

[pythonprogrammer]

А вот мне как раз чертовски не нравится такой подход к маппингу урлов. Чтобы найти, какая вьюха обрабатывает "/services/", надо все файлы, содержащие вьюхи, вручную перерыть.

[Neutral]

Это для больших проектов справедливо, а когда на весь проект два-три файла с вьюхами — достаточно удобно.
Ну и можно в app.url_map._rules посмотреть, чтобы совсем руками не рыть.

[tuupic]

Так можно и без декораторов обойтись и в одном месте это хранить
app.add_url_rule('/', view_func=views.index)
flask.pocoo.org/docs/0.10/patterns/lazyloading/

[ILYHA]

Добавлю немного актуальности:

@async
def send_async_email(app, msg):
    with app.app_context():
        mail.send(msg)