Flask est un micro-framework web pour Python publié sous licence BSD. Il est basé sur Werkzeug, Jinja2, MarkupSafe, ItsDangerous et Click.
La version 0.11 de Flask a été publiée le 29 mai 2016, sous le nom de code « Absinthe ». La version précédente, la 0.10.1, remontait au 14 juin 2013, soit presque trois ans.
Longtemps prévue pour être la version 1.0, cette version sort finalement sous le numéro 0.11, amputée de quelques changements controversés. La nouvelle interface en ligne de commande de Flask a ainsi été modifiée pour ne pas dépendre de fonctionnalités spécifiques à la bibliothèque Click.
Il s'agit de la première version de Flask à sortir depuis la création du Pallets Projects. Le Pallets Projects est un passage à la gestion communautaire de plusieurs projets initialement développés et gérés par Armin Ronacher seul. Parmi ces projets, on retrouve Flask et plusieurs développements Python ayant servi de base à celui-ci.
Ce changement de gestion devrait permettre de sortir des nouvelles versions de Flask plus souvent. Une nouvelle version du site web du projet est prévue en même temps que la prochaine version du microframework.
Modifications notables :
- le navigateur est arrêté lors des recharges de fichiers plutôt que d'afficher une page « connexion réinitialisée », afin de rendre le développement plus agréable ;
- nouveau support de la ligne de commande.
Liste de changements :
flask.jsonify
sérialise maintenant les listes. Cette fonctionnalité était désactivée dans les versions antérieures car elle pose un problème de sécurité avec les vieux navigateurs (ECAMScript 4). Il a été estimé que grâce à la correction dans ECMAScript 5, cette vulnérabilité est obsolète.Ajout du signal
before_render_template
.Ajout de
**kwargs
àflask.Test.test_client
pour pouvoir passer des paramètres nommés supplémentaires au constructeur deflask.Flask.test_client_class
.Ajout du paramètre de configuration
SESSION_REFRESH_EACH_REQUEST
qui contrôle le comportement des cookies pour les sessions permanentes. S'il est égal àTrue
, à chaque requête, la durée de vie des cookies est étendue. S'il est àFalse
, elle n'est étendue que si le cookie est modifié par la session. Le comportement est inchangé pour les sessions non permanentes et les cookies expirent quand le navigateur est fermé.Support de types MIME JSON personnalisés pour les données entrantes.
Possibilité de renvoyer des tuples de la forme (response, headers) depuis une fonction vue.
Ajout des classes
flask.Config.from_json
,flask.Config.from_mapping
,flask.Flask.config_class
,flask.config.Config.get_namespace
.Par défaut, en dehors du mode
DEBUG
, les templates ne sont plus rechargés automatiquement. Ceci peut être configuré avec le paramètre de configurationTEMPLATES_AUTO_RELOAD
.Ajout de la commande
flask
et du moduleflask.cli
pour démarrer le serveur de déboguage avec le système de ligne de commandeclick
. Il est recommandé d'employer cette méthode plutôt que l'ancienne (flask.run()
) car c'est plus rapide et plus sûr. Cette méthode remplace aussiFlask-Script
.Le logger est activé par défaut même si
debug
est désactivé. Le format de log est codé en dur, mais la gestion de log par défaut peut être désactivée avec le paramètre de configurationLOGGER_HANDLER_POLICY
.Ajout du flag de configuration EXPLAIN_TEMPLATE_LOADING qui dit à Flask d'expliquer comment il trouve les fichiers templates. Cela aidera les utilisateurs à déboguer quand les templates non-voulus sont actifs.
Les blueprints sont traités dans l'ordre dans lequel ils ont été enregistrés pour le chargement des templates.
Les tests ont été portés vers
py.test
.request.json
est déprécié en faveur derequest.get_json()
.Ajout des séparateurs
pretty
etcompressed
à la méthodejsonify()
. Par défaut,JSONIFY_PRETTYPRINT_REGULAR=True
et la sortie dejsonify()
est "pretty-printée".Ajout d'un caractère "nouvelle ligne" à la fin des réponses
JSON
pour satisfaire certains clients qui ne prennent pas en charge les réponses ne respectant pas cette norme UNIX. (pull request #1626.La méthode
OPTIONS
fournie automatiquement est maintenant correctement désactivée si l'utilisateur a enregistré une règle avec la versionoptions
en minuscule (demande #1288).flask.json.jsonify
gère maintenant le typedatetime.date
(pull request #1326).Ne pas passer les informations sur les exceptions déjà rattrapées aux
teardown handlers
de contexte (pull request #1393).Authoriser les sous-classes personnalisées d'environnement
Jinja
(pull request #1422).flask.g
a maintenant les méthodespop()
etsetdefault()
.Activation de l'auto-échappement par défaut dans
flask.templating.render_template_string
(pull request #1515).flask.ext
est rendu obsolète (pull request #1484). Il faut maintenant utiliser la syntaxefrom flask_extension import
plutôt quefrom flask.ext.extension import
. La seconde affiche un avertissement au lancement de l'application.La fonction
send_from_directory
soulève une exceptionBadRequest
si le nom du fichier n'est pas considéré comme valide par le système d'exploitation du serveur (pull request #1763).Ajout d'un paramètre de configuration
JSONIFY_MIMETYPE
(pull request #1728).Les exceptions déclenchées pendant la gestion de
teardown
ne laissent plus traîner des contextes d'application cassés.
Une version 0.11.1 a été publiée quelques jours après, le 7 juin 2016 avec quelques corrections de bogues.
Aller plus loin
- Site officiel (1056 clics)
- Page PyPI (161 clics)
- Liste des modifications (217 clics)
- Code source (github) (120 clics)
- Annonce officielle (131 clics)
# Merci
Posté par barmic . Évalué à 10.
Moi qui croyais que ce framework était un peu mou, je suis content d'avoir des nouvelles ;-)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Merci
Posté par G.bleu (site web personnel) . Évalué à 5.
Que Flask en lui-même n'évolue que peu me semble logique : c'est un produit à la fois simple et mature.
C'est plutôt l'activité de son écosystème (ses extensions qui le rende si modulable et puissant) qu'il faut mesurer pour avoir une idée de la vivacité du projet.
[^] # Re: Merci
Posté par barmic . Évalué à 10.
flask → flasque / mou tout ça…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Merci
Posté par fasthm . Évalué à 8.
En fait tu te réjouissais que le projet ait pris de la bouteille.
La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".
[^] # Re: Merci
Posté par Antoine . Évalué à 9.
Vos blagues, qui sont toutes du même tonneau, poussent le bouchon un peu loin. À force de se gondoler, la goutte d'eau va faire déborder le vase. Tant va la cruche à l'eau…
[^] # Re: Merci
Posté par Aldebaran (site web personnel) . Évalué à 3.
Tant va la cruche au nain qu'à la fin il vomit ?
# Mais pourquoi click ?
Posté par G.bleu (site web personnel) . Évalué à 10. Dernière modification le 16 juin 2016 à 11:16.
Le plus gros soucis de cette version pour moi est l'arrivée de click en dépendance.
L'issue (https://github.com/smurfix/flask-script/issues/97) résume bien le bordel :
mitsuhiko (Armin Ronacher, le créateur de flask), écrit le 7 mai 2014 :
Réponse de miguelgrinberg (grosse pointure dans la communauté, a notamment écrit le flask mega tutorial) le 9 mai 2014
S'ensuit quelques discutions sur le comment et malheureusement pas assez le pourquoi.
Et la dernière réponse du fils à l'heure actuelle (miguelgrinberg du 4 avril 2015) pleine de bon sens :
Au final je vois ça comme un bel exemple de NIH, Armin est connu pour avoir créé tout un écosystème d'excellente qualité (maintenant le projet pallets) ce qui fait que les dépendances des ses projets sont presque tout le temps d'autres projets à lui (par exemple toutes les dépendances de Flask, ainsi que toutes les dépendances de ces dépendances).
Il a donc créé Click qui est un super outil, simplement dans l'écosystème Flask il existe déjà Flask-Script qui marche bien et est le standard de-facto.
S'ensuit des arguments foireux en faveur de Click sans pour autant prendre en compte ceux de Flask-Script, au hasard que ça va foutre un énorme bordel dans les extensions qui sont justement la force de Flask. On nous explique c'est in-dis-pen-sable d'avoir un module de command line livré dans Flask (c'est vrai que faire
$ flask ma-commande
c'est tellement mieux que$ ./manage.py ma-commande
, ça justifie largement un changement majeur).Puis une situation de pourrissement : rien ne se passe en 2 ans, le fil est abandonné depuis 1 an.
La question majeure de la migration des extensions reste en suspend et on passe l'évolution à mi-mot : le module command line est dans la release, mais ce n'est qu'un détail qu'il utilise Click.
À terme on aura donc au sein d'une même application des extensions en Flask-Script et d'autres en Click, le tout parce que l'ancienne implémentation du module d'autoreload de Flask était pas top, oui ça n'a aucun rapport…
[^] # Re: Mais pourquoi click ?
Posté par jihele . Évalué à 3.
Merci pour ces éclairages.
Je pense que c'est lié à ce que les "release notes" présentent comme "changements notables" et que je ne comprenais pas bien (et que j'ai donc mal traduits), peut-être précisément parce que c'était écrit de façon floue parce qu'à demi-mots comme tu dis.
# Par rapport à Django
Posté par Ermaion (site web personnel) . Évalué à 3.
Ce framework m’a l’air plus simple et plus épuré mais pourrait-il remplacer Django dans toutes les situations ?
J’ai l’impression que Python 3 n’est pas encore correctement supporté.
[^] # Re: Par rapport à Django
Posté par jihele . Évalué à 7.
Django a plein de fonctionnalités (notamment gestion de BDD, génération automatique de backend). Si tu n'en as pas besoin, alors autant prendre Flask que de s'encombrer de tout ça. Si tu en as besoin, c'est probablement plus simple de prendre Django que de tout recréer.
Aujourd'hui, Python 3 est officiellement pris en charge.
[^] # Re: Par rapport à Django
Posté par G.bleu (site web personnel) . Évalué à 10.
C'est deux philosophies complémentaires :
- d'un côté Django est sans prise de tête, tout est déjà pensé et intégré pour un workflow standard
- de l'autre Flask est pensé pour être le plus simple possible et répondre aux besoin par des extensions
Au niveau fonctionnalités je dirais que les deux sont grossos-modo équivalents, par exemple :
Django ORM ==> SQLAlchemy
Django admin ==> Flask admin
Django rest framework ==> Flask restful
La principale différence serait que Flask permet de choisir son ORM là où Django repose sur son module interne (il y a eu des initiatives pour permettre d'utiliser mongoDB, mais je ne sais pas où ça en est).
Personnellement j'adore la simplicité de Flask, cela permet d'intégrer des personnes n'ayant pas d'expérience avec la techno très simplement et ça encourage à lire le code source.
Au final il n'y a pas de mauvais choix entre les deux [vendredi c'est permis]et si ton équipe est parti sur l'un des deux ça veut dire que t'as éviter PHP et nodejs donc te plains pas ![/vendredi c'est permis]
J'ai plusieurs applications en production sur Flask + Python 3, jamais eu le moindre bug à cause de Flask.
[^] # Re: Par rapport à Django
Posté par flan (site web personnel) . Évalué à 10.
Django permet depuis très longtemps d'intégrer ses propres moteurs (autrement dit un adaptateur à une base de données) à l'ORM de base, et tu peux depuis longtemps faire du LDAP ou du MongoDB.
À côté de ça, tu peux maintenant (mais c'est récent, Django 1.8 ou 1.9) changer d'ORM et utiliser un autre (par exemple SQLAlchemy). De façon générale, Django est maintenant beaucoup plus modulaire : tu peux changer son moteur de template (pour du Jinja2, au hasard) et son ORM.
[^] # Re: Par rapport à Django
Posté par ff9097 . Évalué à 2.
Tu saurais donner ton avis sur les deux ORM ?
[^] # Re: Par rapport à Django
Posté par Meewan . Évalué à 5.
En très rapide et en essayant de pas troller:
sqlalchemy est assez proche de SQL et tu as un meilleur controle sur le SQL qui sera généré. Il a donc tendance a être plus puissant. À l'opposé l'ORM de django est beaucoup plus facile a utiliser pour les requetes classiques (un Object.get(id=1) on peut pas faire plus simple).
A toi de voir lequel est plus adapté a tes besoins, si tu as énormément de requetes simples je dirais de prendre plutot l'orm de django.
Pour les performances je ne sais pas j'ai pas de moyens de mesurer mais [avis]je dirais que l'orm de django est plus lent[avis]
[^] # Re: Par rapport à Django
Posté par flan (site web personnel) . Évalué à 4.
Malheureusement, non : je n'ai quasiment pas utilisé SQLAlchemy.
Concernant celui de Django : il s'est beaucoup amélioré à chaque version. Il permet de faire très facilement des requêtes simples et facilement des requêtes complexes. De plus, django debug toolbar permet de voir quelles sont les requêtes SQL effectuées, donc c'est assez facile de voir quelles sont les requêtes problématiques (et donc quelles sont les requêtes qu'on peut laisser telles quelles).
Si tu fais gaffe aux perfs, l'ORM de Django possède pas mal de subtilités qui permettent d'affiner le SQL effectué (soit en restant en pur Python, soit en aidant un peu, soit en écrivant directement le SQL). Par exemple, tu peux faire des jointures propres sans trop de souci.
[^] # Re: Par rapport à Django
Posté par vermillon . Évalué à 7.
J'utilise la 0.10.1 en python 3.5 depuis quelques mois et ça marche sans problème (pour mon usage).
# Bottle vs Flask
Posté par Yth (Mastodon) . Évalué à 9.
Dans le genre framework web léger en Python il y a Bottle aussi, je connais un peu mais pas du tout Flask.
Quelles différences majeures entre les deux ?
Bottle a l'air bien plus minimaliste, donc la question pourrait être qu'est-ce qu'apporte Flask par rapport à Bottle ?
Yth.
[^] # Re: Bottle vs Flask
Posté par Antoine . Évalué à 6.
Bottle est assez rigide, contrairement à la souplesse de Flask qui permet de le glisser un peu partout.
Pour le recyclage, je crois que les deux vont à la consigne.
[^] # Re: Bottle vs Flask
Posté par steph1978 . Évalué à 1.
Alors là je ne suis pas du tout en phase. Une flak ça se conserve précieusement, surtout si c'est un kado. Un bottle, ça se met au recyclage /.
[^] # Re: Bottle vs Flask
Posté par dzecniv . Évalué à 2.
Bottle n'a rien par défaut, n'a aucun écosystème, il ne recharge même pas le serveur de développement par défaut. Un collègue a choisi Bottle et est vite repassé sous Django. Avec ces frameworks minimalistes, soit on a de bonnes raisons de ne rien utiliser (pas d'ORM, rien pour lancer des tests, pas de BD de test, pas de plugins, etc), soit on va devoir tout refaire ce que Django fait déjà…
ImportD https://importd.readthedocs.io/en/latest/ (le D est pour Django) permet de démarrer Django très simplement, en un seul fichier, de la même manière que Flask (son avantage le plus vanté).
[^] # Re: Bottle vs Flask
Posté par Yth (Mastodon) . Évalué à 5.
Ma question était sérieuse et n'appelait pas un troll, surtout aussi peu informé…
Yth.
[^] # Re: Bottle vs Flask
Posté par wilk . Évalué à 2.
Ce n'est pas parce qu'il n'y a rien par défaut qu'on n'utilise rien ou qu'il faut tout refaire par soit même… Au contraire même, on choisi ce qu'on utilise donc potentiellement plus de choses si besoin.
Inversement, dans un framework ou tout est inclus, si on doit utiliser quelque chose qui n'est pas inclus, là on va devoir "tout refaire".
# Pyramid
Posté par wilk . Évalué à 8.
Puisqu'on est dans les comparaisons, j'aime bien Pyramid pour sa flexibilité impressionnante. Je dirai même que c'est plus un toolkit de fabrication de framework qu'un framework. Donc si on a envie de se faire son framework aux petits oignons c'est l'idéal.
https://trypyramid.com/
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.