Au tout départ, j’ai eu connaissance seulement de CherryPy et de Django. Première impression de grosse communauté pro pour Django qui jouit d’une énorme communication. J’ai donc commencé par lui. Je n’ai pas aimé la structure ubuesque des fichiers, ni l’appellation MVC biaisée dont l’explication officielle ne m’a pas convaincue, ni les libertés prises AMHA avec les bonnes pratiques de programmation, ni le serveur en carton, ni l’ORM par défaut. Je suis donc passé à CherryPy.

CherryPy: grand respect des bonnes pratiques, serveur de production, framework minimaliste. Pile poil dans mes goûts. J’ai donc étendu mes recherches aux autres micro-frameworks. Bottle, Flask et CherryPy m’apparaissent relativement équivalents dans une première approche assez poussée, au détail près que CherryPy est le seul à avoir un serveur de production, et est à mon sens plus élégant. Bottle a pour lui d’être un poil plus concis, et probablement plus facile à apprendre. “I gave it a try”, mais je n’ai rien trouvé dans Flask d’intéressant pour me détourner de CherryPy ou de Bottle.

Vient le problème de l’hébergement. Une autre raison qui m’a fait oublié assez vite Flask est que Gandi ne supporte le Python 3 qu’en python3.2 (en PaaS). Or Flask en Python 3, c’est du 3.3 minimum. Il y a donc incompatibilité rédhibitoire. Pareil, chez les hébergeurs que j’ai testé (PythonAnywhere, AlwaysData, Heroku), CherryPy est plutôt mal géré par rapport à ses concurrent: la faute à son serveur HTTP justement, puisque les hébergeurs propose le leur (Apache). J’ai quand même réussi à sortir une appli CherryPy sur PythonAnywhere mais au prix d’une magouille pas très propre (en fait j’ai utilisé une config’ Bottle au départ, que j’ai adaptée à CherryPy… Bref !).

Au final, CherryPy reste mon framework préféré. De mon point de vue, si on est en SaaS ou en auto-hébergement, aucune raison d’utiliser un autre framework. Par contre en PaaS, utiliser Bottle reste le meilleur choix à mes yeux.

Enfin, je ne comprends vraiment pas l’engouement pour Django. Ne pas réinventer la roue me semble un argument fallacieux: Python doit être modulaire (import snippet). Et si c’est pour faire valoir des compétences sur le marché du travail, ou mettre en production rapidement, creuser PHP et WordPress (et/ou Symfony, Drupa, Joomla) me semble plus judicieux.

http://cork.firelet.net/

Que je te conseille d’utiliser sur le forum de l’afpy.

Par contre, j’ai un soucis en Python 3.1 : les accents ne passent pas les formulaires, alors que pas de soucis pour ça en Python 2.6, c’est assez paradoxal..