This is a really disingenuous generalization. If it's not Flask, it's messy and confusing? Telling every framework developer who's not the author of this one library that their code is crap not only isn't a great way to be taken seriously, it's wrong and just kind of mean.
I dunno, I've recently started getting into it and "convoluted" is one word that has occurred to me more than once. Handlers vs signals, application and request context, context locals, local proxies, etc.. Probably there's a good reason for all these and the docs make a decent attempt to lay them out but overall my unscientific first impression is that it's not exactly a pinnacle of simplicity.
Those are just different names for the same thing. Maybe the docs are a bit too in-your-face with the contexts but I rather expose people to it early to avoid issues down the line.
Django for instance does not have equivalents for application and request contexts and the end result is that people often write thread unsafe code and you can only have one application per Python interpreter. Flask does not have those restrictions. You can have as many Flask applications living side by side. And that is possible because of the contexts.
Global proxies to local state are another beast entirely. They are "easy" in that they remove the need to pass application and request objects through every called function, but they are not "simple" -- they rely on intimate details and peculiarities of Python's module and import system, and its capacity for thread-local state, not to mention Python's robust context unwinding features in the case of exceptions. Overuse of context-proxies leads to the same software engineering challenges as overuse of globals, in that it becomes difficult to reason about the calling semantics of functions which rely on context state being present, or mutate context state through proxies. For example, in order to test a view function, you will at a minimum need to set up an application context, but also need to set up any custom context your app relies on. It's not always obvious how to do this, leading to documentation [1] that I notice has already been confusing people on the mailing list.
So I wouldn't conflate the two mechanisms. Application- and request-local context is a pre-requisite for multi-tenant applications and a conceptual simplification. Module-level proxies are a cute trick that makes programmers' lives easier, but undoubtedly creates more convoluted semantics and internal operation.
[1]: http://flask.pocoo.org/docs/testing/#faking-resources-and-co...
Yes, it's not the best solution, but passing things around isn't either.
There is a good reason for why Werkzeug (which Flask is based on) is 15000 lines of code.
Repeating his "I had to make X big to support all of wsgi/http so anyone who made a similar framework but much smaller has made it incomplete or too succint and clever in a bad way" is not evidence.
You say:
>bottle's smaller size means either the implementation is incomplete or the implementation is too clever or both.
That's a statement of fact (actually a dichotomy of facts). What's the evidence to support these are the only two possible options?
The mere fact that Armin had to make Werkzeug bigger "owing to complexities of wsgi/http" is not proof.
To take it as proof is to assume his coding (and understanding of wsgi/http) as the golden standard by which the Bottle developer should be measured.
Who said this is the case? For one, it took him a year after Bottle to support Python 3, so he might not be that focused, anyway.
My problem is that, the way he and you say it, "incomplete" implies broken or lacking, whereas "too clever" implies fancy tricky code that's too succinct for it's own good.
How about the third option that he needlessly convoluted Werkzeug to work around wsgi/http edge cases that no one really faces, whereas Bottle has been pragmatic about it?
Or the fourth option, that Werkzeug is needlessly verbose, whereas Bottle is not "too clever" but just as clever as needed?
I've tried both frameworks, and looked at the code for both, and I'm of the opposite opinion.
Yours is not a very suggestion. It presupposes what is asked to provide evidence for. That's called a circular argument.