Sortie de Flask 0.11

Posté par jihele le 15 juin 2016 à 19:46. Édité par dovik, palm123, Nils Ratusznik, Nÿco et Stefane Fermigier. Modéré par bubar🦥. Licence CC By‑SA.

Étiquettes :

juin

2016

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.

Flask

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 de flask.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 configuration TEMPLATES_AUTO_RELOAD.
Ajout de la commande flask et du module flask.cli pour démarrer le serveur de déboguage avec le système de ligne de commande click. 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 aussi Flask-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 configuration LOGGER_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 de request.get_json().
Ajout des séparateurs pretty et compressed à la méthode jsonify(). Par défaut, JSONIFY_PRETTYPRINT_REGULAR=True et la sortie de jsonify() 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 version options en minuscule (demande #1288).
flask.json.jsonify gère maintenant le type datetime.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éthodes pop() et setdefault().
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 syntaxe from flask_extension import plutôt que from flask.ext.extension import. La seconde affiche un avertissement au lancement de l'application.
La fonction send_from_directory soulève une exception BadRequest 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 (1055 clics)
Page PyPI (160 clics)
Liste des modifications (216 clics)
Code source (github) (119 clics)
Annonce officielle (130 clics)

# Merci

Posté par barmic le 16 juin 2016 à 07:41. É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) le 16 juin 2016 à 09:29. Évalué à 5.
  
  Moi qui croyais que ce framework était un peu mou
  
  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 le 16 juin 2016 à 11:36. É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 le 16 juin 2016 à 20:42. É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 le 16 juin 2016 à 21:00. É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) le 17 juin 2016 à 09:04. Évalué à 3.
        
        Tant va la cruche au nain qu'à la fin il vomit ?
# Mais pourquoi click ?

Posté par G.bleu (site web personnel) le 16 juin 2016 à 11:13. É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 :

Mon plan est que d'ici le mois prochain il y ait une nouvelle release de Flask avec Click embarqué ainsi que la recommandation de l'utiliser
[…]
Vu combien d'extensions utilisent Flask-Script actuellement et à quel point il est devenu populaire, j'aimerai qu'on puisse trouver une solution pour tout migrer sur Click sans pour autant causer à tous beaucoup de frustration.
[…]
Pour répondre à la question évidente pourquoi pas Flask-Script:
Flask-Script est vieux et victime de deux changements majeurs dans Flask. Le principal problème est que Flask-Script lance un contexte de requête même si il n'y a pas de raisons de faire cela.
Flask-Script charse l'application très tôt ce qui cause des soucis pour le rechargeur (reloader) pendant le développement.En particulier cela veut dire qu'une erreur de syntaxe va faire crasher le rechargeur. Ce veut aussi dire qu'avec le rechargeur activé, le code de plus haut niveau est exécuté deux fois. L'intégration de click dans Flask résout cela.
[…]

Réponse de miguelgrinberg (grosse pointure dans la communauté, a notamment écrit le flask mega tutorial) le 9 mai 2014

@mitsuhiko J'ai jeté un coup d’œil à ta couche d'intégration de Click. Il semblerait que le code qui s'occupe de résoudre les deux limitations de Flask-Script que tu as mentionner ne sont pas spécifiques à Click du tout.
En fait, en quelques minutes de hacking, j'ai été capable de résoudre les soucis avec Flask-Script de la même manière.
[…]

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 :

Ce que les gens semble oublier, c'est que nous sommes en train de parler de systèmes gestion de ligne de commande. Il s'agit de systèmes simples dont les patterns sont connus et résolus depuis longtemps. Oui, Click a une façon originale de définir les arguments d'une ligne de commande ce qui le rend pratique et même fun à utiliser, mais au bout du compte, de mon point de vue la ligne de commande dans une application Flask est une partie extrêmement petite de mes problèmes, honnêtement ce ne fait pas de différences pour moi de devoir utiliser Click ou Flask-Script car les deux rendent la tache simple. Et Flask-Script a l'avantage d'être compatible avec argparse, ce que Click n'est pas.
[…]

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 le 16 juin 2016 à 11:56. É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) le 16 juin 2016 à 13:29. É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 le 16 juin 2016 à 13:39. Évalué à 7.
  
  Ce framework m’a l’air plus simple et plus épuré mais pourrait-il remplacer Django dans toutes les situations ?
  
  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.
  
  J’ai l’impression que Python 3 n’est pas encore correctement supporté.
  
  Aujourd'hui, Python 3 est officiellement pris en charge.
- [^] # Re: Par rapport à Django
  
  Posté par G.bleu (site web personnel) le 16 juin 2016 à 15:28. É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 l’impression que Python 3 n’est pas encore correctement supporté.
  
  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) le 16 juin 2016 à 19:18. É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 le 16 juin 2016 à 19:27. Évalué à 2.
      
      Tu saurais donner ton avis sur les deux ORM ?
      - [^] # Re: Par rapport à Django
        
        Posté par Meewan le 17 juin 2016 à 11:43. É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) le 17 juin 2016 à 19:22. É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 le 16 juin 2016 à 15:29. Évalué à 7.
  
  J’ai l’impression que Python 3 n’est pas encore correctement supporté.
  
  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) le 17 juin 2016 à 11:00. É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 le 17 juin 2016 à 18:13. É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 le 17 juin 2016 à 19:43. Évalué à 1.
    
    Pour le recyclage, je crois que les deux vont à la consigne.
    
    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 le 18 juin 2016 à 04:53. É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) le 18 juin 2016 à 07:37. Évalué à 5.
    
    Bottle n'a rien par défaut, n'a aucun écosystème
    Mako, Jinja2, Cheetah pour les templates.
    Il y a une quinzaine de plugins dont un ORM pour SQlite, et des plugins pour Redis, Mongo, SQLAlchemy, memcached, et même Werkzeug.
    
    il ne recharge même pas le serveur de développement par défaut.
    C'est faux, si tu le lances en disant « serveur de dev » il recharge automatiquement.
    
    Ma question était sérieuse et n'appelait pas un troll, surtout aussi peu informé…
    
    Yth.
  - [^] # Re: Bottle vs Flask
    
    Posté par wilk le 18 juin 2016 à 09:11. É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 le 17 juin 2016 à 18:33. É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.