Легкий python веб-фреймворк: Bottle

[@Nengchak]

Спасибо за обзор. Очень напоминает php фреймворк Silex.

[@JC_Piligrim]

Пробовал его, даже пытались что-то разрабатывать.

Он удобен только для вещей вроде «я и моя хомепага». Основная идея автора — весь фреймворк в одном .py-файле, без установки каких-либо зависимостей (что в каких-то ситуациях именно то, что нужно). Кинул 3 файла (фреймовк, аппу и sqlite-базу) на сервер — и всё завелось. Самое то для лёгких серверов, где бекенд — не основная часть и нужно быстро стартануть что-то очень простое. Просто и со вкусом.

Но для чего-то более серьёзного и масштабного, что ещё и разрастается со временем он по всем параметрам сливает Flask'у, на котором, в итоге, и делаем проекты.

[@equand]

Согласен… Хотя в принципе можно переделать ботлу, что я и сделал. Только ИМХО в итоге фляга/джанга и вышла :).

[@KAdot]

Чем он лучше Flask?

[@JRazor]

Скорость разработки небольших проектов. Если ничего громадного не требуется — набросал по-быстрому и поставил.

[@maximbo]

А что во Flask не так с «набросал по-быстрому и поставил»?

[@SteveNers]

Ну впринципе они довольно похожи, но в любом случае bottle проще и что-то сделать на нем займет меньше времени

[@Kentzo]

«в любом случае» — замечательный аргумент.

[@SteveNers]

Факт того, что bottle проще довольно очевиден, его как бы для этого и задумывали. Я же не говорю, что простота всегда лучше, просто для маленьких проектов код на bottle писать проще, чем на flask'e

[@leventov]

Хелоуворлд на Фласке не длиннее, чем на Ботле. Аргумент предложил JC_Piligrim — можно кинуть bottle.py рядом со скриптом приложения и не возиться с установкой пакетов, виртуальными средами, если нет прав и т. д.

[@lega]

У Bottle недавно было сильное преимущество — поддержка Py3, но сейчас Flask тоже умеет.
Bottle быстрее по «hello world пузомерке», +фреймворк в одном файле, + есть готовые адаптеры к разным шаблонизаторам и серверам.
Flask может быть интересен какими-то плагинами, вроде их кол-во больше чем у Bottle.
Если любите копаться в коде фреймворков, Bottle — простой, меньше кода.

Вообщем сейчас особой разницы нет, лично я предпочитаю Bottle, т.к. его для многого хватает — использую его более 4 лет и переходить на Flask смысла нет.

[@vabue]

Есть старенькая, но всё ещё актуальная презентация с сравнением пайтоновских микрофрейморков.

[@q_styler]

Познакомился с Bottle, когда проходил курсы по MongoDB. Милый, простой, понятный.
Но, честно говоря, не вижу смысла в «ein framework ein file». Потому как для любого мало-мальски серьёзного проекта кроме фрэймворка придётся использовать целую гору других файлов.

[@overmes]

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

[@rsludge]

Очень похоже на очередной клон Sinatra.

[@hellman]

Одна из сильнейших сторон фреймворка — механизм шаблонов.

Не щупал другие шаблонизаторы, но по ощущениям шаблонизатор bottle чересчур минималистичен. Я бы не сказал, что это сильная сторона bottle.

Чтобы воспользоваться шаблонизатором, достаточно написать такую легкую конструкцию:
template('template_name', name=name, number=number, foo=bar)

По моему гораздо красивше использовать декоратор @view("template_name") и вернуть из функции dict с подстановками.

[@batment]

Следует отметить, что bottle.py дружит с gevent'ом — это позволяет выжать гораздо больше запросов в секунду даже на относительно слабых машинах.

[@kivsiak]

flask кстати тоже.

[@maleficxp]

Также Bottle предоставляет нам очень очень крутую возможность: писать любой python код внутри шаблона. Чтобы вызвать питон, достаточно в начале строки поставить %. Например:

%a = 100500
%for i in xrange(a):
    <div class="image_{{i}}"><img src="......{{i}}.jpg"></div>
%end 

А что написать цикл на шаблонизаторе Bottle без использования кода на python нельзя?

[@SteveNers]

Какой-то странный у вас вопрос. А на чем вы хотели цикл написать?

[@leventov]

Может быть, на специальных шаблонных тегах?

[@chersanya]

Зачем вводить специальные теги (т.е. ещё один язык), если и так есть питон и его можно применить? Во Flask (Jinja) так сделано — со специальными тегами — не сказал бы что удобнее на вид.

[@SteveNers]

Да, конечно, давайте создадим свой новый синтаксис непонятно зачем. Чем питон не устраивает? Это ведь очень простой случай, а бывает, что у нас есть огромный словарь, в котором еще есть куча списков и.т.д. Так зачем выдумывать что-то новое, когда питон является одним из самых удобных языков для таких целей?

[@leventov]

Я всего лишь предположил, что имел ввиду maleficxp. Я не специалист в движках шаблонов, но раз и в Джанге, и Флаксе для циклов, условий и т. д. все специальные теги, видимо, на это есть причины.

[@aruseni]

В Django так сделано по крайней мере по двум причинам:

1. Разграничение доступа — в ряде случаев доступ к редактированию шаблонов есть у относительно широкого круга лиц. Соответственно, необходимо, чтобы управлять отображением чего-либо на сайте эти люди могли, но вот выполнять произвольный Python-код — нет. При этом с Django поставляется, например, тэг ssi (чтение любого файла в шаблоне), но чтобы использовать его с каким-либо файлом, одна из родительских директорий должна быть указана в настройке ALLOWED_INCLUDE_ROOTS. То есть, как видите, по умолчанию всё сделано так, чтобы из шаблонов можно было делать только то, что необходимо в шаблонах, а не что угодно.
2. Предполагается, что есть бэкэнд-разработчики, а есть фронтэнд-разработчики. Соответственно, фронтэнд-разработчики, которые не знают Python, таким образом получают возможность самостоятельно писать шаблоны.

[@chersanya]

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

[@maleficxp]

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

[@maleficxp]

Да, именно это я и имел в виду. Согласно идеологии MVC логика живет отдельно от представления. То есть логику пишет программист на языке программирования, а шаблоны верстает дизайнер на языке шаблонов.
Лично я много работаю со Smarty (php), там, конечно, тоже можно вставить код php в шаблон, но даже в документации написано, что так делать не рекомендуется.
Вот же дураки, напридумывали непонятных тэгов, когда все нормальные пацаны прямо на python-е пишут
Виноват, конечно, надо было сразу понять, что раз фреймворк микро-, то дизайнер и программист это одно лицо, и не задавать глупых вопросов.

[@aleXoid]

Ну это с Django Bottle играет явно в разных весовых категориях. Не могу даже представить себе варианта работы большой команды с проектом на Bottle. Тут же типовой usecase — поднять на скорую руку веб мордочку или слепить сайт на несколько страниц. С таким использованием его применяют в основном админы и backend программисты для служебных целей, а не команда верстальщиков.

И если это так — то зачем что-то усложнять дополнительными шаблонными тегами?

[@lega]

Не могу даже представить себе варианта работы большой команды с проектом на Bottle.

Почему нет? В Bottle есть все необходимое, на нем можно сделать свою архитектуру, свой фреймворк (свою «джангу») и т.п.
Как раз для больших проектов иногда удобнее сделать свою архитектуру, чем использовать чужую (навязанную фреймворком).
А вот про Django ходят слухи, что в больших приложении в конечном счете 95% функционала джанги (в основном плагинов) переписывается, т.е. же штатные комментарии сразу рекомендуют «выкинуть».

Поэтому такие как Bottle, Flask, Pyramid (по гибкости) тоже могут рассматриваться на роль в больших проектах.

[@aleXoid]

Понятно, что все можно переписать =) Про 95% переписываемого функционала Django — немного погорячились. Плагины плагинами, но ORM, генератор админки, синхронизация БД, шаблонизатор, консольные команды и пр. А в 1.6 — еще и неплохие миграции из коробки — это то что особо не переписывают. Только админку всячески декорируют.

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