Then again, I also dislike some of the magic in Flask.

We're getting rid of all the magic we can avoid. With 0.7 barely any magic is left with the notable exception of backwards compatibility.

For what reason?

Magic can come to haunt you when you get stuck. For e.g. flask has thread locals where the request variable gets populated with the current request's context dynamically.

For the most part though, Flask is very magic free and the source is small enough to quickly figure out whats going on.

Because I just dislike magic.

"does magic that is frowned upon by some people."

Can you elaborate?

I would describe it more carefully. Bottle's advantage that it's self contained and in a single file, however bottle's design also hides away the application object from you which makes it quite hard to have more than one of them. It is possible with the stacked object thing and I think they changed it even to make it possible to do what Flask did, but when Flask started at least there was a design difference there.

By now I really would like to see them merge, but Bottle wants to stick to the design idea of just having one file which Flask will never be able to do because of the dependencies.

Any reasons why they should merge if they are so different?

Merge is an excellent idea when two projects, frameworks, etc have the same goals (Not necessarily the same features). For example The Pylons Project taking BFG as is base and making Pyramid, with all the experience from Pylons community and BFG. This will make changes on both sides of the community but brings a new Framework with the possibility of improvement. I guess the idea is take the best from both frameworks y make a new one, better, with a big community, and a lot of knowledge from the previous experiences.

Consolidation of resources and talents. That is all I can think of.

An example would be that Bottle creates an application object implicitly and assumes that all resources(templates, static files, etc.) are relative to the cwd. However the WSGI specification doesn't define what the cwd points to so you have to work around that for some servers.

If you use Flask you create the application object explicitly and pass it the name of the module, relative to which Flask looks up resources.

> assumes that all resources(templates, static files, etc.)

Reading the source, I see no evidence of this.

https://github.com/defnull/bottle/blob/master/bottle.py#L161...

I must have been mistaken for static files, for templates however it is the case:

https://github.com/defnull/bottle/blob/master/bottle.py#L263...

You can override it but you would have to do that for every call to `template` or by monkey patching `TEMPLATE_PATH`.

In the big picture, I don't see having to write a wrapper function for template rendering with a fixed template_lookup argument being a big deal (I'm basing all of my judgments on source alone, I've only fiddled with either framework).

It's still a problem for modularity, something like Flask's blueprints are basically impossible for Bottle.