Комментарии 11
НЛО прилетело и опубликовало эту надпись здесь
Так они похожи по сути. Создаем админку. Как они могут отличаться?!
На счет +- DJANGO VS FLASK
Вот примерный анализ + Фляги:
1. Меньший размер, мало зависимостей, можно быстро писать приложения в одном .py файле
2. Отдельные компоненты из которых состоит Flask лучше аналогов из Django
3. Explicit is better than implicit, никаких автоимпортов и другой магии кроме threadlocals (которые Django тоже использует)
Из минусов:
1. Надо привыкнуть к чтению документации из кучи разных мест (запросы — Werkzeug, шаблоны — Jinja2, ORM скорее всего SQLAlchemy и так далее).
2. Сторонних компонент явно меньше
3. Начинающим сложнее — слишком много свободы и непонятно что делать.
На счет отдельных компонент:
всего две зависимости: Werkzeug и Jinja2 и очень тонкая прослойка между ними.
Werkzeug умеет много всякого хорошего, например вот такой вот замечательный, интерактивный дебаггер: werkzeug.pocoo.org/docs/debug/
Jinja2, же, очень хороший шаблонизатор с синтаксисом Django. Лучше хотя бы тем, что при ошибках в шаблонах умеет показывать stacktrace и банально работает быстрее.
Если взять третью компоненту — ORM, то это скорее всего будет SQLAlchemy (некоторые еще Peewee используют, я его даже не смотрел). А алхимия сама по себе лучше ORM Django. Можно спорить о удобности и привычности синтаксиса, но как ни крутить — позволяет больше и не заставляет писать сырой SQL в относительно сложных случаях.
Тут скорее дело в том, что Django это комбайн все в одном. Разработчики распыляют свои усилия по достаточно большой кодовой базе. И в каждой своей части, Django работает хоть и не плохо, но хуже чем отдельные специализированные решения. Да, можно сказать что у Django лучше связанность компонент, но на самом деле Flask от слабой связанности не сильно страдает.
На счет +- DJANGO VS FLASK
Вот примерный анализ + Фляги:
1. Меньший размер, мало зависимостей, можно быстро писать приложения в одном .py файле
2. Отдельные компоненты из которых состоит Flask лучше аналогов из Django
3. Explicit is better than implicit, никаких автоимпортов и другой магии кроме threadlocals (которые Django тоже использует)
Из минусов:
1. Надо привыкнуть к чтению документации из кучи разных мест (запросы — Werkzeug, шаблоны — Jinja2, ORM скорее всего SQLAlchemy и так далее).
2. Сторонних компонент явно меньше
3. Начинающим сложнее — слишком много свободы и непонятно что делать.
На счет отдельных компонент:
всего две зависимости: Werkzeug и Jinja2 и очень тонкая прослойка между ними.
Werkzeug умеет много всякого хорошего, например вот такой вот замечательный, интерактивный дебаггер: werkzeug.pocoo.org/docs/debug/
Jinja2, же, очень хороший шаблонизатор с синтаксисом Django. Лучше хотя бы тем, что при ошибках в шаблонах умеет показывать stacktrace и банально работает быстрее.
Если взять третью компоненту — ORM, то это скорее всего будет SQLAlchemy (некоторые еще Peewee используют, я его даже не смотрел). А алхимия сама по себе лучше ORM Django. Можно спорить о удобности и привычности синтаксиса, но как ни крутить — позволяет больше и не заставляет писать сырой SQL в относительно сложных случаях.
Тут скорее дело в том, что Django это комбайн все в одном. Разработчики распыляют свои усилия по достаточно большой кодовой базе. И в каждой своей части, Django работает хоть и не плохо, но хуже чем отдельные специализированные решения. Да, можно сказать что у Django лучше связанность компонент, но на самом деле Flask от слабой связанности не сильно страдает.
Самое интересное то, что оригинальный автор — создатель Flask
А вообще — люди заменяют шаблонизатор на Jinja довольно часто в Djnago, т.к. возможностей больше дает для манёвра.
А вообще — люди заменяют шаблонизатор на Jinja довольно часто в Djnago, т.к. возможностей больше дает для манёвра.
Ну, скажем так, не создатель… Но слегка «руку приложил». Мигель Гринберг фотограф и как то связан с кино. Программирование то же его увлечение. А разработчиком Flask считается Armin Ronacher он же является одним из основателей Pocoo Team, автором известного шаблонизатора для языка Python Jinja2 и нескольких библиотек с открытым исходным кодом. Сейчас Армин живет в Австрии и работает партнером Sentry и консультантом для Fireteam.
Возник вопрос про следующий параграф
Не совсем понял зачем менять 8025 на что-то еще и почему оно меньше 1024. Спасибо за труды.
(venv) $ python -m smtpd -n -c DebuggingServer localhost:8025
… необходимы права администратора, поскольку порты ниже 1024 являются портами только для администратора. В качестве альтернативы...
Не совсем понял зачем менять 8025 на что-то еще и почему оно меньше 1024. Спасибо за труды.
Это из-за MAIL_PORT=587
Спасибо за ответ, Александр, но 587 — это не для открытия порта на 'listening', как в случае с дебетовым smtp сервером, а для обращения к удаленному smtp серверу, я уверен, что для обращения к удаленному серверу по порту ниже 1024 не нужно иметь прав администратора, иначе интернетом пользоваться могли бы только администраторы. Я считаю, что это ошибка и изначально в тексте было не 8025, а число ниже 1024, а потом, порт исправили, а текст под ним нет. Спасибо.
Спасибо, автокоррекция. Имелся ввиду дебаговый smtp сервер. :)
Посмотрел у Гринберга… :) Он этот абзац вообще выкинул. Или он мне приснился и я его сам сочинил.
Спасибо огромное за внимательный разбор статьи! Если будут ещё уточнения и замечания, то пишите — исправлю.
Все верно, еще 23 марта у Мигеля было это в посте, а 30 марта уже не было
Ссылка на веб архив
Поэтому не приснился он Вам. :)
Ссылка на веб архив
Поэтому не приснился он Вам. :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мега-Учебник Flask, Часть 7: Обработка ошибок (издание 2018)