
Bottle: Single-File Python Web Framework - dpatru
http://bottlepy.org/docs/dev/index.html
======
puzzler314
It looks exactly like Itty (since 2009, updated as recently as 2011):
<https://github.com/toastdriven/itty>

The only differences I see are minor name changes. I'll have to compare the
source code.

EDIT: It appears to be an unrelated codebase with a lot of improvements (for
example, proper cookie support). Looks like I'll need to be updating my
projects.

------
drats
The disqus comments on the page are entirely correct: it should come standard
with python (or something like it). I've used it a few times and it's just
elegant and would match "batteries included" perfectly.

~~~
briancurtin
A full web framework is not something you want to come standard with Python.
Putting Bottle, Flask, Django, {your_favorite} inside the standard library
would pretty much kill it. Development would screech almost to a halt since
Python generally releases less often than any of these frameworks.

For example, we released 3.2 in Spring '11. There will be no new features
released until 3.3, which is slated to come out in Fall '12 - about 1.5 years.
In comparison, the popular Flask framework is about 1.5 years old and has had
~8 point releases, and it can add features whenever it wants at whatever rate
it wants. If Armin wants to make a new feature today, he can do that and
release it today if he wants.

On top of that, web frameworks are like a religion that we would have to
choose. There's currently a separation of church and state that has worked
well in the community and allowed different frameworks to do different things
at different paces. I think we should keep that.

~~~
andybak
I agree on you regarding a full stack web framework with it's own community
such as Django but a lightweight, minimal web framework would be a useful
addition to the standard library, surely?

~~~
sitkack
Putting something in standard lib effectively kills it. It doesn't mature, it
turns into an adult child actor. Forever 'young'

I don't think their really should be a standard library for Python. There
should be a base, and a much more proactively revved base library, but not a
standard library. Part of installing python would be installing the base.

~~~
wisty
I think the standard library is great. It's good to know that there is a
"batteries complete" library that you can really on, that won't change its API
for years. Being standard, it's well documented, well vetted, and lots of
people know it.

There needs to be a wider repo, but pip / easy_install does that OK.

What does need to change - there needs to be more "library2" modules. urllib
wasn't good enough, so they made "urllib2". Likewise, there's lots of old,
outdated modules that could be supplanted.

~~~
sitkack
Brian, you are completely wrong. The x2 modules need to go away. They are
confusing, the "standard lib" is mostly shit. And it is fixed in time. If it
were writing I would describe it as a, "hack, rambling, incoherent, amateur"
piece of work.

The usability of pip is abysmal. You don't even get usage by just typing "pip"
with no arguments. Look at brew for direction.

Python makes me sad.

------
heydenberk
It seems like being single-file is mostly gimmick. What are the drawbacks to
creating a folder with an __init__.py and a handful of readably-long files?

~~~
dpatru
JQuery is single file too and that's a big part of it's attraction. Simplicity
is a huge plus, not only for users, but also for the developer who is forced
to be disciplined.

I haven't used bottle yet (just starting), but I'm very impressed with the
templating code which seems very powerful and simple. Including the templating
system along with the rest of the framework in a single file, forced the
developer to think about it more.

~~~
andybak
But part of the advantage with jQuery being single-file there is ease of
deployment. Python isn't quite as handicapped in this areas as Javascript is.
A single line in requirements.txt can add something as complex a complex
library to your project without a second thought.

~~~
lifthrasiir
And you'll end up with the complexity of dependencies with mismatched and/or
incompatible versions. Adding a dependency explicitly to the source code is
the ultimate, albeit somewhat inefficient, solution which is often useful. In
Python, for example, BeautifulSoup has long recommended this practice.

See also the SQLite amalgamation for another example of a single-file
deployment: <http://www.sqlite.org/amalgamation.html>

------
reustle
I've used this quite a bit and love it. My favorite part is that there are no
dependencies (that aren't in the standard library).

------
ajray
This is exactly what I was looking for. Got up this morning and it was #1 on
HN. This is why I <3 HN. Thanks for solving my problems again :-)

------
rednaught
Bottle has been around for a while and is great. But is there something new or
about to reach proverbial "1.0" status?

For those interested in single-file frameworks, there is also Mojolicious in
Perl and Fat-Free in PHP.

------
gabi38
How does it compare with flask?

~~~
lost-theory
I used bottle for one project, but switched to Flask for everything once it
was released. In my opinion the future is very bright for Flask (extensions,
blueprints, community). The code and libraries it is built on top of are all
extremely high quality.

~~~
StavrosK
Basically, bottle was here and things were good, and then Armin decided to
announce Flask as an April Fools joke and ate poor bottle's lunch.

Bottle and Flask are similar enough, but I think Flask has more momentum and
support.

------
overshard
Extremely well built and easy to use from a UX (DX? Developer Experience?)
perspective. I have recently been using Sinatra and am loving these extremely
minimal frameworks. We just need something like Heroku for Python. Gondor
maybe?

~~~
brandon
Well, in fairness, Heroku is now the Heroku for Python. The new Cedar stack
(unofficially) supports Python, and some of the frameworks are already being
tested on it
([http://docs.pylonsproject.org/projects/pyramid_cookbook/dev/...](http://docs.pylonsproject.org/projects/pyramid_cookbook/dev/deployment/heroku.html))

I managed to get into the betas for both ep.io and gondor, but neither has
anything near the polish that the Heroku guys have had years to work on.

------
jarito
Is it just me or is the first example on their front page a great example of
XSS? Unless their standard string formatting routines are performing escaping,
this is pretty awful.

------
defroost
Seems to me to be another micro web framework influenced heavily by Sinatra.

~~~
psykotic
Do you know enough about the Python ecosystem to make that assessment? Aaron
Swartz's web.py was around as a single-file web micro-framework years before
Sinatra even existed. An early version of reddit, after they switched from
Common Lisp to Python, was built starting with web.py.

~~~
defroost
I know that web.py was around years before Sinatra. But URL routing in Bottle
is more similar to Sinatra than it is to the URL dispatching via a tuple at
the top of a file. Even so, perhaps Bottle is influenced more by web.py. That
doesn't mean there aren't a ton of ports of Sinatra (like Express for node.js,
Scalatra) or those influence by Sinatra like itty
([http://toastdriven.com/blog/2009/mar/07/itty-sinatra-
inspire...](http://toastdriven.com/blog/2009/mar/07/itty-sinatra-inspired-
micro-framework/)) or even perhaps Flask.

I even noticed a comment above that said Bottle looks just like Itty. Yet
because I brought up the Ruby framework that Itty is essentially a port of,
I'm getting down-voted like crazy. I will never understand why Python people
dislike Ruby so much, and vice versa.

~~~
psykotic
> But URL routing in Bottle is more similar to Sinatra than it is to the URL
> dispatching via a tuple at the top of a file.

Decorators, a Python 2.5 feature, weren't around when web.py was first
released, so they couldn't have been used initially. Even after Python 2.5
came out, it took some time for decorators to be widely embraced. But routing
and other kinds of dispatching (e.g. adapters and multimethods) are an obvious
and indeed commonplace use of them.

I didn't down-vote you. I did get ever so slightly annoyed with your
implication that Sinatra was the first to do this kind of thing and therefore
necessarily a source of influence. Neither half of this claim is correct.
Sinatra wasn't the first. Even if it were, it need not have been an influence;
I wouldn't claim that web.py had to have influenced Sinatra just because it
preceded it.

------
OzzyB
I ♥ Bottle!

------
zyfo
Anyone who've used web.py and Bottle (for a real project) and care to comment
on the pros/cons of both? I'm quite familiar with web.py but not so much with
Bottle.

~~~
famousactress
Used it early and extensively for a pretty good sized project. In my
experience what really happens on a long-lived project is that you end up
writing and assembling your own framework on top of the basics that are
provided. Not a bad thing if you think you're gonna end up growing a lot of
your own infra anyways..

I think mostly I'd use microframeworks like this in the future to do small
projects and early prototyping.. or if I thought the project had special needs
that was going to make using something like Django a particularly challenging
match.

~~~
rmk
I used this thing in a desktop app that consumed a RESTful API service and
received notifications (HTTP POSTs) from the API service.

At a high rate, bottle just dies. So if you have a situation where you are
making many requests to it, be careful; your mileage may vary.

~~~
grncdr
What WSGI server were you deploying on? I'm thinking of using Bottle for some
providing some REST services, so any details you can provide would be helpful.

~~~
brandon
I can't speak for the parent poster, but I deployed bottle with the
grandparent poster without any significant performance issues*. This was first
under mod_wsgi, then paste.deploy once mod_wsgi got to be a headache, and now
I'm looking at gunicorn as a simpler alternative to paste.deploy.

So, why the asterisk next to "no issues"? I was able to wedge our app once by
doing frequent, unbuffered, blocking socket.reads for one byte at a time in
our RPC library... the GIL is a fearsome thing and it didn't play well with
this strategy under highly concurrent request loads. I don't see that as a
bottle problem, though.

If you're anticipating high loads, though, I wholly recommend looking at
Brubeck (<http://brubeck.io/>) or Tornado (<http://www.tornadoweb.org/>)

------
eurohacker
what this framework is missing compared to Django

