Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 31
Спасибо за обзор. Очень напоминает php фреймворк Silex.
Пробовал его, даже пытались что-то разрабатывать.
Он удобен только для вещей вроде «я и моя хомепага». Основная идея автора — весь фреймворк в одном .py-файле, без установки каких-либо зависимостей (что в каких-то ситуациях именно то, что нужно). Кинул 3 файла (фреймовк, аппу и sqlite-базу) на сервер — и всё завелось. Самое то для лёгких серверов, где бекенд — не основная часть и нужно быстро стартануть что-то очень простое. Просто и со вкусом.
Но для чего-то более серьёзного и масштабного, что ещё и разрастается со временем он по всем параметрам сливает Flask'у, на котором, в итоге, и делаем проекты.
Он удобен только для вещей вроде «я и моя хомепага». Основная идея автора — весь фреймворк в одном .py-файле, без установки каких-либо зависимостей (что в каких-то ситуациях именно то, что нужно). Кинул 3 файла (фреймовк, аппу и sqlite-базу) на сервер — и всё завелось. Самое то для лёгких серверов, где бекенд — не основная часть и нужно быстро стартануть что-то очень простое. Просто и со вкусом.
Но для чего-то более серьёзного и масштабного, что ещё и разрастается со временем он по всем параметрам сливает Flask'у, на котором, в итоге, и делаем проекты.
Чем он лучше Flask?
Скорость разработки небольших проектов. Если ничего громадного не требуется — набросал по-быстрому и поставил.
А что во Flask не так с «набросал по-быстрому и поставил»?
Ну впринципе они довольно похожи, но в любом случае bottle проще и что-то сделать на нем займет меньше времени
«в любом случае» — замечательный аргумент.
Факт того, что bottle проще довольно очевиден, его как бы для этого и задумывали. Я же не говорю, что простота всегда лучше, просто для маленьких проектов код на bottle писать проще, чем на flask'e
Хелоуворлд на Фласке не длиннее, чем на Ботле. Аргумент предложил JC_Piligrim — можно кинуть bottle.py рядом со скриптом приложения и не возиться с установкой пакетов, виртуальными средами, если нет прав и т. д.
У Bottle недавно было сильное преимущество — поддержка Py3, но сейчас Flask тоже умеет.
Bottle быстрее по «hello world пузомерке», +фреймворк в одном файле, + есть готовые адаптеры к разным шаблонизаторам и серверам.
Flask может быть интересен какими-то плагинами, вроде их кол-во больше чем у Bottle.
Если любите копаться в коде фреймворков, Bottle — простой, меньше кода.
Вообщем сейчас особой разницы нет, лично я предпочитаю Bottle, т.к. его для многого хватает — использую его более 4 лет и переходить на Flask смысла нет.
Bottle быстрее по «hello world пузомерке», +фреймворк в одном файле, + есть готовые адаптеры к разным шаблонизаторам и серверам.
Flask может быть интересен какими-то плагинами, вроде их кол-во больше чем у Bottle.
Если любите копаться в коде фреймворков, Bottle — простой, меньше кода.
Вообщем сейчас особой разницы нет, лично я предпочитаю Bottle, т.к. его для многого хватает — использую его более 4 лет и переходить на Flask смысла нет.
Есть старенькая, но всё ещё актуальная презентация с сравнением пайтоновских микрофрейморков.
Познакомился с Bottle, когда проходил курсы по MongoDB. Милый, простой, понятный.
Но, честно говоря, не вижу смысла в «ein framework ein file». Потому как для любого мало-мальски серьёзного проекта кроме фрэймворка придётся использовать целую гору других файлов.
Но, честно говоря, не вижу смысла в «ein framework ein file». Потому как для любого мало-мальски серьёзного проекта кроме фрэймворка придётся использовать целую гору других файлов.
Очень похоже на очередной клон Sinatra.
Одна из сильнейших сторон фреймворка — механизм шаблонов.
Не щупал другие шаблонизаторы, но по ощущениям шаблонизатор bottle чересчур минималистичен. Я бы не сказал, что это сильная сторона bottle.
Чтобы воспользоваться шаблонизатором, достаточно написать такую легкую конструкцию:
template('template_name', name=name, number=number, foo=bar)
По моему гораздо красивше использовать декоратор
@view("template_name") и вернуть из функции dict с подстановками.
Следует отметить, что bottle.py дружит с gevent'ом — это позволяет выжать гораздо больше запросов в секунду даже на относительно слабых машинах.
Также Bottle предоставляет нам очень очень крутую возможность: писать любой python код внутри шаблона. Чтобы вызвать питон, достаточно в начале строки поставить %. Например:
%a = 100500 %for i in xrange(a): <div class="image_{{i}}"><img src="......{{i}}.jpg"></div> %end
А что написать цикл на шаблонизаторе Bottle без использования кода на python нельзя?
Какой-то странный у вас вопрос. А на чем вы хотели цикл написать?
Может быть, на специальных шаблонных тегах?
Зачем вводить специальные теги (т.е. ещё один язык), если и так есть питон и его можно применить? Во Flask (Jinja) так сделано — со специальными тегами — не сказал бы что удобнее на вид.
Да, конечно, давайте создадим свой новый синтаксис непонятно зачем. Чем питон не устраивает? Это ведь очень простой случай, а бывает, что у нас есть огромный словарь, в котором еще есть куча списков и.т.д. Так зачем выдумывать что-то новое, когда питон является одним из самых удобных языков для таких целей?
Я всего лишь предположил, что имел ввиду maleficxp. Я не специалист в движках шаблонов, но раз и в Джанге, и Флаксе для циклов, условий и т. д. все специальные теги, видимо, на это есть причины.
В Django так сделано по крайней мере по двум причинам:
- Разграничение доступа — в ряде случаев доступ к редактированию шаблонов есть у относительно широкого круга лиц. Соответственно, необходимо, чтобы управлять отображением чего-либо на сайте эти люди могли, но вот выполнять произвольный Python-код — нет. При этом с Django поставляется, например, тэг ssi (чтение любого файла в шаблоне), но чтобы использовать его с каким-либо файлом, одна из родительских директорий должна быть указана в настройке ALLOWED_INCLUDE_ROOTS. То есть, как видите, по умолчанию всё сделано так, чтобы из шаблонов можно было делать только то, что необходимо в шаблонах, а не что угодно.
- Предполагается, что есть бэкэнд-разработчики, а есть фронтэнд-разработчики. Соответственно, фронтэнд-разработчики, которые не знают Python, таким образом получают возможность самостоятельно писать шаблоны.
Да, именно это я и имел в виду. Согласно идеологии MVC логика живет отдельно от представления. То есть логику пишет программист на языке программирования, а шаблоны верстает дизайнер на языке шаблонов.
Лично я много работаю со Smarty (php), там, конечно, тоже можно вставить код php в шаблон, но даже в документации написано, что так делать не рекомендуется.
Вот же дураки, напридумывали непонятных тэгов, когда все нормальные пацаны прямо на python-е пишут
Виноват, конечно, надо было сразу понять, что раз фреймворк микро-, то дизайнер и программист это одно лицо, и не задавать глупых вопросов.
Лично я много работаю со Smarty (php), там, конечно, тоже можно вставить код php в шаблон, но даже в документации написано, что так делать не рекомендуется.
Виноват, конечно, надо было сразу понять, что раз фреймворк микро-, то дизайнер и программист это одно лицо, и не задавать глупых вопросов.
Ну это с Django Bottle играет явно в разных весовых категориях. Не могу даже представить себе варианта работы большой команды с проектом на Bottle. Тут же типовой usecase — поднять на скорую руку веб мордочку или слепить сайт на несколько страниц. С таким использованием его применяют в основном админы и backend программисты для служебных целей, а не команда верстальщиков.
И если это так — то зачем что-то усложнять дополнительными шаблонными тегами?
И если это так — то зачем что-то усложнять дополнительными шаблонными тегами?
Не могу даже представить себе варианта работы большой команды с проектом на Bottle.
Почему нет? В Bottle есть все необходимое, на нем можно сделать свою архитектуру, свой фреймворк (свою «джангу») и т.п.
Как раз для больших проектов иногда удобнее сделать свою архитектуру, чем использовать чужую (навязанную фреймворком).
А вот про Django ходят слухи, что в больших приложении в конечном счете 95% функционала джанги (в основном плагинов) переписывается, т.е. же штатные комментарии сразу рекомендуют «выкинуть».
Поэтому такие как Bottle, Flask, Pyramid (по гибкости) тоже могут рассматриваться на роль в больших проектах.
Понятно, что все можно переписать =) Про 95% переписываемого функционала Django — немного погорячились. Плагины плагинами, но ORM, генератор админки, синхронизация БД, шаблонизатор, консольные команды и пр. А в 1.6 — еще и неплохие миграции из коробки — это то что особо не переписывают. Только админку всячески декорируют.
Я много всяких чудес насмотрелся за свою жизнь, но сильно сомневаюсь в адекватности архитектора, который для крупного бизнес-проекта в большой команде выберет микрофреймворк. Пусть даже как базу для последующего изменения. Imho
Я много всяких чудес насмотрелся за свою жизнь, но сильно сомневаюсь в адекватности архитектора, который для крупного бизнес-проекта в большой команде выберет микрофреймворк. Пусть даже как базу для последующего изменения. Imho
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Легкий python веб-фреймворк: Bottle