https://github.com/bottlepy/bottle
Considering the following points of view, I chose Bottle, which I thought was good overall.
I wanted to use Python 3 for this ISUCON.
It's been many years since 3 came out, and 2/3 of the major libraries are being supported.
In Python, the appearance and writing style did not change significantly even if it changed from 2 to 3, and there was a point that even users of 2 series who had never used 3 series could read and write without problems.
Well-known frameworks supported Python3, so they all seemed to work.
In ISUCON, it is necessary to solve the problem in a short time, and I want the questioner to concentrate on that, so the learning cost of the framework is required to be low.
Bottle depends only on the standard library. If you use the standard library, you can expect to be familiar with it, and you can also find documents and information.
If you rely on other third-party libraries, it will take more time to explore the framework usage and options.
CherryPy
http://cherrypy.org/
--There is history and name recognition --There seems to be no dependence on third parties --Development is ongoing ――The way to write a handler is class-based, but it can be written simply.
It didn't have a template engine, and it had more files and larger size than Bottle.
Flask
http://flask.pocoo.org/
It was used in the Python implementation in ISUCON 4.
--High name recognition --There is a lot of information in Japanese --Development is ongoing --Handlers are easy to write like Sinatra
It also has functions for large-scale apps such as Blueprints, and the framework is large.
Tornado
https://github.com/tornadoweb/tornado
――Is your name recognition reasonable? --There is a little dependence on third parties --Development is ongoing (Facebook has it now) ――The way to write a handler is class-based, but it can be written simply.
Personally my favorite framework.
Since it supports asynchronous IO, it may be suitable for applications such as ISUCON where a large number of bench markers are accessed. However, since asynchronous IO is processed efficiently with a single thread and there is a habit, I did not adopt it because I thought it would be bad if the participants were confused.
Maybe it's better to replace it with Tornado when doing the final problem in Python.
Falcon
http://falconframework.org/
The speed seems to be a selling point.
The scale was large.
Django
https://www.djangoproject.com/
I thought it was too heavy.
Pyramid
http://www.pylonsproject.org/
I thought it wouldn't match ISUCON somehow.
Recommended Posts