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.
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.
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.
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.
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.
If we look back at this in a few years, maybe it's worth considering as usage grows, APIs are more locked down, and a clear winner shines through. Right now, any inclusion would be months of bike shedding, assuming any of these framework developers are willing to give up external maintenance of their products and go 100% into the standard library.
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.
See also the SQLite amalgamation for another example of a single-file deployment: http://www.sqlite.org/amalgamation.html
For those interested in single-file frameworks, there is also Mojolicious in Perl and Fat-Free in PHP.
Bottle and Flask are similar enough, but I think Flask has more momentum and support.
"The big difference is that Flask is based on other technologies such as Werkzeug and Jinja2 that exist for a longer time and it does not try to reinvent things. Bottle on the other hand tries to stick to the one-file approach.
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.
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.
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.
Python people don't dislike Ruby, they dislike the Ruby community's habit of assuming that Ruby somehow did it first and did it better. :3
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.
You've got to decide for yourself where your 'reinventing the wheel' cutoff point is. For some people it's flipping binary bits, for others, anything lower level than configuring Drupal modules is just a waste of time.
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.
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/)
I would have been happy to use Bottle if i) it had a feature that lets me specify FDs to watch and associated callbacks, like what I could do if I directly controlled the server select loop and ii) Python had built-in support for reader-writer locks.
Twisted had async support but it's documentation could be more comprehensive. I understood the programming model, classes and methods well enough to use it for my project only after tinkering with code, not from just reading documentation or looking at examples.