Pourquoi l'implémentation Python d'ISUCON 5 a utilisé Bottle

https://github.com/bottlepy/bottle

Compte tenu des points de vue suivants, j'ai choisi Bottle, ce que j'ai trouvé globalement bon.

Compatible avec Python 3

Je voulais utiliser Python 3 pour cet ISUCON.

Cela fait de nombreuses années que 3 est sorti, et 2/3 des principales bibliothèques sont supportées.

En Python, l'apparence et le style d'écriture n'ont pas changé de manière significative, même s'ils passaient de 2 à 3, et il y avait un point que même les utilisateurs de 2 séries qui n'avaient jamais utilisé 3 séries pouvaient lire et écrire sans problème.

Les frameworks bien connus étaient compatibles avec Python 3, ils semblaient donc tous fonctionner.

La dépendance est uniquement une bibliothèque standard

Avec ISUCON, il est nécessaire de résoudre les problèmes en peu de temps, et je veux que les questionneurs se concentrent là-dessus, de sorte que le coût d'apprentissage du cadre doit être faible.

Bottle ne dépend que des bibliothèques standard. S'il s'agit d'une bibliothèque standard, vous pouvez vous attendre à la connaître, et vous pouvez également trouver des documents et des informations.

Si vous comptez sur d'autres bibliothèques tierces, il faudra plus de temps pour explorer l'utilisation et les options du framework.

Cadre non choisi

CherryPy

http://cherrypy.org/

--Il y a une histoire et une reconnaissance de nom --Il ne semble y avoir aucune dépendance vis-à-vis de tiers

• Le développement est en cours «La façon d'écrire un gestionnaire est basée sur les classes, mais elle peut être écrite simplement.

Il n'avait pas de moteur de modèle, et il avait un plus grand nombre et une plus grande taille de fichiers que Bottle.

Flask

http://flask.pocoo.org/

Il a été utilisé dans l'implémentation Python dans ISUCON 4.

• Hautement connu
• Il y a beaucoup d'informations en japonais
• Le développement est en cours
• Les gestionnaires sont faciles à écrire comme Sinatra

Il a également des fonctions pour les applications à grande échelle telles que Blueprints, et l'échelle du cadre est grande.

Tornado

https://github.com/tornadoweb/tornado

―― Votre nom est-il si bon? --Il y a un peu de dépendance vis-à-vis des tiers

• Le développement est en cours (maintenant Facebook a) «La façon d'écrire un gestionnaire est basée sur les classes, mais elle peut être écrite simplement.

Personnellement mon cadre préféré.

Puisqu'il prend en charge les E / S asynchrones, il peut convenir à des applications telles que ISUCON où un grand nombre de points de repère sont accessibles. Cependant, je ne l'ai pas adopté car j'avais l'habitude de traiter efficacement les E / S asynchrones avec un seul thread, donc j'ai pensé que ce serait mal si les participants étaient confus.

Il vaut peut-être mieux le remplacer par Tornado lors du dernier problème en Python.

Falcon

http://falconframework.org/

La vitesse semble être un argument de vente.

L'échelle était grande.

Django

https://www.djangoproject.com/

Je pensais que c'était trop lourd.

Pyramid

http://www.pylonsproject.org/

Je pensais que cela ne correspondrait pas à ISUCON.