I did something similar a while back, in case any-one's still interested ..
Python web micro-framework battle
11–20 of 59 posts
Re: Python web micro-framework battle
#12Line count is a silly way to score when all are around the same anyway (fewer than 100 lines). And the framework line count is another metric that shouldn't matter. That said, really the only valid point here against Flask is Python 3 support. Other than that Bottle and Flask are pretty much on par with each other.
Flask has the advantages of fast templates, strong WSGI features, serious unit testability at the app and library level, complete documentation...
but didn't you read the presentation ? templates are out man. Write your HTML as string concatenations "" + helloworld + "" right inside your __init__.py or YOU'RE NOT COOL.
Re: Python web micro-framework battle
#13Earlier quoted context omitted.
Flask has the advantages of fast templates, strong WSGI features, serious unit testability at the app and library level, complete documentation...
but didn't you read the presentation ? templates are out man. Write your HTML as string concatenations " " + helloworld + " " right inside your __init__.py or YOU'RE NOT COOL.
The presentation stated that templates were not part of the assessment criteria - since with most microframeworks template systems are either not bundled or easily replacable.
Re: Python web micro-framework battle
#14Earlier quoted context omitted.
but didn't you read the presentation ? templates are out man. Write your HTML as string concatenations " " + helloworld + " " right inside your __init__.py or YOU'RE NOT COOL.
The presentation stated that templates were not part of the assessment criteria - since with most microframeworks template systems are either not bundled or easily replacable.
hey you're right, this wasn't very apparent from the slides.
Re: Python web micro-framework battle
#15Where does one draw the distinction between micro- and megaframeworks? Or, for that reference, just a "framework"?
Re: Python web micro-framework battle
#16The author's examples for cherrypy were way more complicated than they needed to be, and they didn't take performance into account. I also find some of the conclusions about its documentation and wsgi questionable. The author also drops some frameworks immediately due to maturity, but then fails to rank the remainder based on that. What about ipv6 and proper Unicode support? What about http/wsgi compliance? And of course, at the end they show all the extras the frameworks have but don't take those into account.
Re: Python web micro-framework battle
#17Where does one draw the distinction between micro- and megaframeworks? Or, for that reference, just a "framework"?
Things a company will ask you to know is a megaframeworks. Else, it's a micro or simply framework.
Obviously, I'm not serious here; but there's some truth in it. I.e. You'll see some companies ask for django or rails developers; not for flask python hacker right ;-)
Re: Python web micro-framework battle
#18Line count is a silly way to score when all are around the same anyway (fewer than 100 lines). And the framework line count is another metric that shouldn't matter. That said, really the only valid point here against Flask is Python 3 support. Other than that Bottle and Flask are pretty much on par with each other.
> Python 3 support
Will come eventually. Right now the topic comes rarely up and it requires a ton of work on the Werkzeug side to make it work in a way that is user friendly. That being said, Flask and Jinja2 are not the problem here. The former easily works on Python 3 and the latter already does (just that we don't have any users on Python 3 yet).
Re: Python web micro-framework battle
#19I have no idea how the LOC numbers of Flask come together though. Flask itself is 1.4KLOC, Jinja2 is 6.5KLOC and Werkzeug is 10KLOC (all measured without tests). Even if you add them up you don't end up with 32KLOC.
Re: Python web micro-framework battle
#20To count out sessions and templating means truly "micro." I can't think of many useful web applications that do not require these to some extent.
With those criteria, I'm sort of switching between Flask and Tornado right now.
Speed is a major consideration with any python framework, too. You've got serious threading concerns. Even with Tornado, advertised as non-blocking, the default solution is nginx running against a whole bunch of tornado threads. ...