Avertissement: je suis l'auteur de tipfy et webapp2.
Un gros avantage de s'en tenir à webapp (ou à son évolution naturelle, webapp2) est que vous n'avez pas à créer vos propres versions pour les gestionnaires de SDK existants pour le framework de votre choix.
Par exemple, différé utilise un gestionnaire d'application Web. Pour l'utiliser dans une vue Flask pure, en utilisant werkzeug.Request et werkzeug.Response, vous devrez l'implémenter différé (comme je l'ai fait ici pour tipfy).
La même chose se produit pour les autres gestionnaires: blobstore (Werkzeug ne prend toujours pas en charge les requêtes de plage, vous devrez donc utiliser WebOb même si vous créez votre propre gestionnaire - voir tipfy.appengine.blobstore ), mail, XMPP et ainsi de suite, ou d'autres qui seront inclus dans le SDK à l'avenir.
Et la même chose se produit pour les bibliothèques créées avec App Engine à l'esprit, comme ProtoRPC , qui est basé sur webapp et aurait besoin d'un port ou d'un adaptateur pour fonctionner avec d'autres frameworks, si vous ne voulez pas mélanger webapp et votre-framework-of- gestionnaires de choix dans la même application.
Ainsi, même si vous choisissez un framework différent, vous finirez a) d'utiliser webapp dans certains cas particuliers ou b) d'avoir à créer et maintenir vos versions pour des gestionnaires ou des fonctionnalités SDK spécifiques, si vous les utiliserez.
Je préfère de loin Werkzeug à WebOb, mais après plus d'un an de portage et de maintenance des versions des gestionnaires de SDK qui fonctionnent nativement avec tipfy, j'ai réalisé que c'était une cause perdue - pour soutenir GAE sur le long terme, le mieux est de rester proche de webapp / WebOb. La prise en charge des bibliothèques SDK est un jeu d'enfant, la maintenance devient beaucoup plus facile, elle est plus à l'épreuve du temps car les nouvelles bibliothèques et fonctionnalités du SDK fonctionneront immédiatement et il y a l'avantage d'une grande communauté travaillant autour des mêmes outils App Engine.
Une défense webapp2 spécifique est résumée ici . Ajoutez à ceux que webapp2 peut être utilisé en dehors d'App Engine et qu'il est facile à personnaliser pour ressembler à des micro-frameworks populaires et vous avez un bon ensemble de raisons convaincantes d'y aller. De plus, webapp2 a de grandes chances d'être inclus dans une future version du SDK (c'est extra-officiel, ne me citez pas :-) ce qui le fera avancer et apportera de nouveaux développeurs et contributions.
Cela dit, je suis un grand fan de Werkzeug et des Pocoo et j'ai beaucoup emprunté à Flask et à d'autres (web.py, Tornado), mais - et, vous savez, je suis partial - les avantages de webapp2 ci-dessus devraient être pris en compte.
flask-babel
pour la prise en charge de plusieurs langues etflask-seasurf
pour le support CSRF pour sécuriser mes formulaires.