Posts Tagged ‘Framework python’

Les micro-frameworks Python : Flask, Bottle, Itty, Newf et importd

dimanche, août 21st, 2016

Suite au succès phénoménal de Flask, qui a plus d’étoiles sur GitHub que Django, et à celui remarquable de Bottle, j’ai poursuivi ma réflexion personnelle sur les microframeworks. C’est un sujet auquel je m’étais fortement intéressé en 2009, il y a 7 ans donc, lors de la soudaine prolifération de microframeworks Python.

Sinatra, l’inspiration vint encore du Ruby

Tout comme Ruby on Rails a été dès 2004 le grand précurseur des frameworks web MVC de nouvelle génération, Sinatra a été dès 2007 le précurseur des microframeworks web. Sinatra a rendu l’écriture d’application web radicalement plus aisée grâce à sa syntaxe claire et concise :

require 'sinatra'

get '/' do
'Hello world!'
end

WSGI, la condition technique

Le standard Python WSGI (Web Server Gateway Interface) décrit dans la PEP 333 de 2003, mise à jour en 2010 par la PEP 3333, a proposé une interface simple permettant de découpler les frameworks web des serveurs web.

Et l’ajout du module wsgiref dans la bibliothèque standard de Python 2.5 en 2006 a permis a tout framework d’être utilisable sans aucune dépendance grâce au petit serveur WSGI qu’il fournit :

from wsgiref.simple_server import make_server

Qu’est-ce qu’un micro-framework ?

En admettant que l’on sache ce qu’est un framework, on doit s’interroger sur le sens de micro. Le Larousse précise :

Préfixe, du grec mikros, petit, indiquant que quelque chose est très petit.

Un micro-framework est donc un très petit framework. L’intérêt de cette démarche est réel pour le développeur car il est plus facile d’apprendre à utiliser un petit framework, qui de plus consomme moins de ressources et impose souvent moins de contraintes.

Il est communément admis que ces microframeworks sont surtout intéressants pour construire de petites applications, la quantité de fonctionnalités des frameworks full-stack justifiant de plus en plus leur usage avec l’augmentation de la taille et des besoins de l’application.

Le moins de lignes de code possible

Un microframework est donc un framework ayant une petite base de code, c’est-à-dire un petit nombre de lignes de code. Encore faut-il qu’il en ait suffisamment pour qu’un développeur ait un intérêt à l’utiliser. Le minimum nécessaire n’est pas forcément facile à évaluer, mais on peut penser que des frameworks comme Newf ou Itty n’en faisaient pas assez pour susciter un réel intérêt chez les développeurs d’applications web.

Tout le framework dans un seul fichier

La théorie de l’ingénierie logicielle a combattu cette pratique au nom d’une meilleure structuration, permettant une bonne séparation des fonctionnalités et donc un débogage et une réutilisation plus facile du code. Pourtant, mettre tout le code dans un seul fichier présente certains avantages, en particulier quand il s’agit de le distribuer. C’est une pratique qui a connu une nouvelle légitimation avec le succès des bibliothèques JavaScript côté client, facilement chargées dans le navigateur web d’une simple ligne :

<script src="https://cdn.net/lib.js"></script>

Bottle est distributed as a single file module alors que Flask est plus classiquement composé de plusieurs fichiers. Flask, le plus populaire des microframeworks Python en est-il donc vraiment un ?

Essayons d’y voir plus clair à l’aide de wc récursifs appliqués sur les répertoire contenant le code source des frameworks, et desquels j’ai retiré le code des tests :

Micro-frameworksFrameworks
NomNewfimportdIttyBottleFlaskTornadoPyramidDjango
Lignes de code1507919584 1796 46922 32722 641122 675
Fichiers Python12112181193853
Étoiles GitHub504543743 87822 00711 9032 05920 717

J’ai ajouté au tableau Django, Pyramid et Tornado, les trois frameworks web Python les plus populaires, et il apparaît clairement qu’en comparaison Flask est bien un microframework, puisque s’il est 1,5 fois plus gros que Bottle, il est 3,5 fois moins gros que Tornado et Pyramid et 19 fois moins gros que Django.

Toute l’application dans un seul fichier

Lorsque l’on utilise les outils d’aide des frameworks classiques pour débuter un projet, on se retrouve devant une arborescence complexe. Par exemple avec Django, si vous évitez les bizarreries et faites les choses normalement :

$ django-admin startproject django_project
$ cd django_project
$ django-admin startapp django_app


django_project
├── django_project
│ ├── __init__.py
│ ├── settings.py
│ ├── urls.py
│ └── wsgi.py
├── django_app
│ ├── admin.py
│ ├── __init__.py
│ ├── migrations
│ │ └── __init__.py
│ ├── models.py
│ ├── tests.py
│ └── views.py
└── manage.py

De même avec Pyramid :

$ pcreate -s starter pyramid_project

pyramid_project
├── CHANGES.txt
├── development.ini
├── MANIFEST.in
├── production.ini
├── pyramid_project
│ ├── __init__.py
│ ├── static
│ │ ├── pyramid-16x16.png
│ │ ├── pyramid.png
│ │ ├── theme.css
│ │ └── theme.min.css
│ ├── templates
│ │ └── mytemplate.pt
│ ├── tests.py
│ └── views.py
├── README.txt
└── setup.py

Ceci est une bonne base pour un gros projet, qui sera bien structuré dès le départ, avec un bon découplage du code, et même les fichiers nécessaires à son packaging ; mais pour beaucoup de projets assez simples, c’est surtout lourd et redondant.

Tous les microframeworks ont donc comme point commun qu’ils sont conçus pour qu’une application toute entière contenue dans un seul fichier soit parfaitement fonctionnelle, et un certain nombre de frameworks qui ne prétendent pas être des microframeworks, comme Tornado, partagent la même approche.

Pas de dépendances… ou beaucoup de dépendances ?

Deux visions opposées peuvent en effet légitimement se défendre lors de la construction d’un microframework :

– pour avoir un framework léger il ne faut aucune dépendances, et se reposer exclusivement sur la bibliothèque standard de Python (Python Standard Library)
– pour avoir un framework léger il faut au contraire se reposer un maximum sur des bibliothèques existantes, fiables et populaires si possible, et se contenter d’offrir une fine couche logicielle permettant de les interfacer correctement

Newf et Itty font bien sûr partie de la première catégorie.

Bottle qui has no dependencies other than the Python Standard Library, et fournit son propre langage de template, fait donc aussi partie de la première catégorie. Mais on peut en plus lui interfacer facilement Mako, Jinja2 et Cheetah, des langages de template Python populaires, ce qui le fait alors déborder sur la deuxième catégorie.

Flask quant à lui est de la seconde catégorie, d’autant que son auteur est Armin Ronacher (mitsuhiko) qui est aussi l’auteur de ses dépendances Werkzeug et Jinja2. Mais si avoir comme dépendances une bibliothèque WSGI et un langage de template est on ne peut plus légitime pour un microframework, l’ajout de la bibliothèque d’interface de ligne de commande Click semble beaucoup plus contestable et relever plutôt du syndrome NIH (Not invented here).

Enfin, la seconde vision a amené à de multiples essais de microframeworks basés sur… Django, le maxi-framework du monde Python ! Et si seul importd a rencontré un certain succès parmi ces projets, je pense que cet oxymore logiciel est un concept vraiment intéressant et que son potentiel n’a probablement pas encore été totalement exploité.

Django 1.4 passe à HTML5 ! et autres nouveautés

mardi, janvier 3rd, 2012

Le 22 décembre dernier est sorti Django 1.4 alpha 1. Comme on peu l’imaginer pour un projet d’une telle ampleur, cette nouvelle version apporte beaucoup de nouveautés. Je me contenterai d’en détailler rapidement cinq qui me semblent particulièrement intéressantes :

    1. Le passage au Doctype HTML5, tous les templates fournis avec Django, en particulier ceux de l’interface d’administration, utilisant donc désormais <!DOCTYPE html>. C’est un choix logique, qui permet d’utiliser toutes les nouvelles fonctionnalités de HTML5 sans plus se soucier de devoir corriger le Doctype.
    2. L’abandon du support de Python 2.4, datant de 2004, mais pas le passage à Python 3. Django supporte et est testé sur Python 2.5, 2.6 et 2.7.
    3. Le nouveau framework de test LiveServerTestCase, compatible avec Selenium et Windmill, pour tester l’interface de votre application web côté client (dans le navigateur web).
    4. La nouvelle option --template pour les commandes startapp et startproject, permettant de leur spécifier aisément un template personnalisé.
    5. La nouvelle clause elif pour la balise if. Elle permettra de ne plus avoir à imbriquer plusieurs if then else et autant d’indentations ou à se définir une balise personnalisée. Alors oui j’ose le dire : c’est pas trop tôt !

On voit donc qu’encore une fois Django continue d’avancer dans la bonne direction, bonifiant sans cesse une base déjà excellente. La seule chose que je regrette encore et toujours, c’est la défiance manifeste de la core team envers l’intégration de django-nonrel… peut-être pour Django 1.5 ?

L’impact de Django

jeudi, septembre 1st, 2011

Armin Ronacher, membre de la Pocco Team, est le principal développeur de nombreux projets libres comme le langage de template Jinja et le microframework Flask, qui sont des programmes Python très populaires et d’excellente qualité.

Le 8 juin, lors du DjangoCon Europe 2011, il a fait une présentation intitulée The Impact of Django ayant un contenu similaire en bien des points à mon article du 6 juin intitulé Et le meilleur framework web Python est… Django !. Vous pouvez voir la conférence en ligne et en consulter ou télécharger les slides.

Bien sûr, il est assez plaisant de constater qu’un développeur, qui n’est pas loin d’être le meilleur au monde sur le sujet, fait une analyse très proche de la mienne en particulier en prenant le contre-exemple de TurboGears et en montrant l’influence du langage de template de Django. Cependant, il ajoute deux éléments  d’analyse, l’un social et l’autre juridique.

Premièrement, Armin pense que, d’une manière assez similaire à Ruby on Rails pour Ruby, Django est actuellement la locomotive du langage Python :

Django is the reason Python is getting that much attention lately.

Ainsi, environ 1 200 des 15 000 paquets disponibles sur PyPi contiendraient “Django” dans leur nom, de même que 10 000 des 77 000 dépôts sur GitHub et 3 000 dépôts sur Bitbucket. Si Python est beaucoup plus utilisé que Ruby en dehors du web, l’importance de ce dernier est telle qu’il est logique que le logiciel qui y est leader soit aussi le leader du langage.

Deuxièmement, Armin lie le succès de la licence BSD dans la communauté Python avec celui de Django et de son écosystème. Ansi 700 des 2 500 paquets sous licence BSD sur PyPI sont classés Django. Et surtout la licence BSD semble être utilisée par des projets assez récents, quand les plus anciens privilégiaient la licence GNU GPL.

Le choix de la licence est quelque chose de fondamental pour un logiciel libre, et il faut réfléchir aux implications réelles qui en découlent. En pratique, dans le contexte du serveur web qui est celui de Django, la licence GNU GPL n’est pas spécialement plus contraignante qu’une licence BSD, n’obligeant pas à redistribuer le code source modifié, et choisir l’une plutôt que l’autre n’a donc pas vraiment de signification pertinente.

Pour ce type de logiciel, si l’on veut voir s’appliquer la puissance du copyleft, il faut utiliser la licence GNU Affero GPL. À titre personnel, c’est la licence que je conseille, mais si l’on veut une licence libérale, alors je trouve effectivement plus clair de choisir une licence BSD qu’une licence GNU GPL vidée de sa substance par le contexte du logiciel serveur.

Et le meilleur framework web Python est… Django !

lundi, juin 6th, 2011

On  observe depuis quelques temps un phénomène de “consolidation” au niveau de beaucoup de logiciels libres. En effet, le modèle du libre est par essence de permettre à chacun de faire se qu’il veut, et donc d’expérimenter et d’innover. Cette dynamique est encore plus sensible quand il s’agit de technologies nouvelles. Mais une fois cette phase d’expérimentation passée, il faut aussi en tirer des conclusions, et se rassembler pour atteindre une masse critique d’utilisateurs et de développeurs, une communauté, qui viabilise le projet sur la durée.

Ainsi Ruby on Rails a été dès 2004 le grand précurseur des frameworks web de nouvelle génération. Mais même dans le monde Ruby des projets concurrents sont apparus, dont le plus important fut Merb, un framework plus léger et plus modulaire. En décembre 2008, Merb et RoR ont fusionné pour donner Ruby on Rails 3, et ainsi rassembler les énergies et les talents.

La situation dans le monde Python, bien que beaucoup plus complexe, a pris le même chemin. En effet, il existait depuis longtemps un grand nombre de technologies web en Python, aussi bien des serveurs d’application comme CherryPy ou Paste, que des langages de templates comme Myghty, Python Server Pages ou Cheetah. On ne peut que constater cette incroyable diversité sur le site officiel de Python. Une blague classique était de dire que Python était un langage tellement simple que chaque développeur pouvait écrire son propre framework. Mais aucun ne proposait un ensemble cohérent et tout intégré… aucun sauf Zope 2, mais qui lui avait comme défaut principal d’être trop intégré !

Ainsi, si sa ZODB, une vraie base de données orientée objet, était en avance techniquement sur un ORM (Object-Relationnal Mapping), c’est-à-dire une simple surcouche pour donner une apparence objet à une base de données relationnelle (SQL), elle a néanmoins fait fuire la majorité des développeurs, qui avaient comme contrainte non négociable de s’interfacer avec des bases de données MySQL, PostgreSQL ou Oracle préexistantes. De plus Zope 2 est connu pour sa courbe d’apprentissage en “Z” (Z-shaped learning curve), qui vous donne d’abord l’impression de régresser et nécessite beaucoup de temps et d’efforts avant d’obtenir un premier résultat intéressant, ainsi que pour mériter le fameux qualificatif “d’usine à gaz logicielle”.

En janvier 2006, Stéphane Fermigier, président fondateur de Nuxeo, essayait d’y voir plus clair grâce à ce schéma :

On peut identifier cinq concurrents directs, de type framework web complet : CPS, Django, TurboGears, Subway et Pylons, ainsi qu’un serveur d’application moderne orienté composant, n’attendant que de servir de base pour de nouveaux frameworks : Zope 3.

Que sont-ils tous devenus ? Il y a d’abord ceux qui sont morts, Subway, de manière classique dans le monde du libre, par désintérêt (des développeurs et/ou des utilisateurs), et CPS, de manière plus originale, en se faisant “seppuku” (d’un point de vue pythonique), en décidant de changer de base technologique, passant de Zope 2 et Python à J2EE et Java.

Restaient donc trois frameworks, Django, un ensemble complet et monolithique d’un côté, et TurboGears et Pylons de l’autre, qui essayaient quant à eux de réutiliser au maximum les nombreux projets python existants. Ainsi, Django a souvent été accusé de souffrir du syndrome NIH (Not Invented Here), voir l’intéressante conférence de Mark Ramm (principal développeur de TurboGears) sur le sujet lors du DjangoCon 2008. Il y eu donc naturellement un rapprochement entre TurboGears et Pylons, et en juin 2007 Mark Ramm annonça que le futur TurboGears 2 serait basé sur Pylons. au grand désarroi de CherryPy.

D’un autre côté apparurent plusieurs frameworks, dont Grok et repoze.bfg, prenant comme base technologique Zope 3, mais en essayant de le rendre plus facile à utiliser et à configurer, par exemple en vous préservant de trop nombreux fichiers ZCML. Et voilà qu’en novembre 2010, Pylons et repoze.bfg fusionnent pour donner naissance à un nouveau framework soutenu par le Projet Pylons et appelé Pyramid, qui se base sur le code source de repoze.bfg et son architecture à composant, Pylons ne pouvant plus évoluer à cause d’un problème de design. Enfin, en décembre, c’est TurboGears qui fusionne avec Pyramid.

Trois frameworks qui ne font donc plus qu’un, espérant qu’en additionnant toutes leurs forces ils pourront constituer un adversaire crédible à Django. Mais un survol du tutoriel rapide m’a fait froid dans le dos : du SQL à la main (c’est bien la dernière chose que je souhaitais revivre) et des décorateurs pour spécifier le langage de template pour chaque view !? Comme en plus je ne suis pas convaincu que l’architecture à composant enthousiasme grand monde, j’ai de gros doutes sur l’avenir de Pyramid.

On en est donc arrivé à un point où les concurrents de Django ont soit disparu, soit fusionné. Alors qu’il a lui continué son chemin sans trop d’embûches, en étant en particulier extrêmement stable technologiquement. Imaginez le cauchemard du développeur TurboGears, qui a d’abord appris Kid, CherryPy et SQLObject dans la version 1, puis Genshi, Paste et SQLAlchemy dans la version 2, et qui doit maintenant ouvrir son esprit à l’architecture composant de Pyramid ! Les développeurs Django n’ont eux jamais eu à vivre ce genre de choses, et ce à mon avis grâce aux excellents choix de design logiciel faits dès le départ :

  1. Le langage de template de Django est devenu un standard, utilisé par le Google App Engine et repris dans de nombreuses autres implémentations comme Jinja et le langage de template de Tornado en Python, ErlyDTL en Erlang, Twig (le langage de template de Symfony2) et H2O en PHP, Liquid en Ruby, Dotiac en Perl, Jangod en Java, NDjango en F#, ou encore djangode de node.js et le langage de template de Dojo en JavaScript. Cette réussite est principalement due à la simplicité de ce langage de template qui est “stupide”, ce qui force à mettre la logique de traitement hors des templates, et n‘a pas une  syntaxe XML, ce qui le rend utilisable facilement par des humains. Enfin, en janvier 2006 c’est le créateur de Python, Guido Van Rossum en personne, qui le consacre comme son choix personnel.
  2. Beaucoup décriaient l’ORM de Django, qu’aucun autre projet n’utilisait, et conseillaient l’utilisation de SQLobject -un changement-… puis de SQLAlchemy -un deuxième changement-, juste pour faire comme les autres frameworks Python… Puis les bases de données NoSQL sont arrivées, que ni SQLobject, ni SQLAlchemy n’ont vocation de supporter (ce n’est plus du SQL !), alors que l’ORM de Django s’adapte elle à la situation grâce au projet Django-nonrel, qui sera je l’espère bientôt intégré dans la branche principale.
  3. Le choix standard du langage de template et de l’ORM a permis et encouragé l’émergence d’un écosystème de nombreuses applications, toutes compatibles entre elles, et de snippets permettant aux développeurs de ne pas sans cesse réinventer la roue logicielle. De plus ils peuvent se baser sur l’un des nombreux sites libres disponibles pour créer les leurs. À l’opposé d’un Pylons qui laissait la liberté de ces choix, et qui n’a donc jamais pu bénéficier d’une dynamique comparable, Django est devenu une plateforme de développement autonome et incroyablement riche.

Ce développement cohérent et linéaire depuis 2005 a permis la constitution d’un large communauté et rendu Django suffisamment crédible et répandu en entreprise pour que l’on puisse trouver assez facilement un travail, un emploi, un job, ou encore un autre travail ou un autre job, de développeur rémunéré à plein temps pour travailler sur une technologie libre qu’il aime (je n’ai pas dit faire du libre), ce qui est encore trop rare.

Alors bien sûr vous pouvez aussi utiliser web2py, Tornado pour faire de l’asynchrone, un des nombreux microframeworks, ou encore créer le vôtre avec WebOb, si vous êtes bons, vous ferez d’excellentes choses. Mais LE meilleur framework web Python, c’est Django !

Mise à jour du 28 juillet 2011 : J’ai rajouté trois liens dans l’article. De plus, Georges Racinet m’a gentiment contacté pour me faire part du fait qu’il est mainteneur de CPS depuis trois ans, et que si le projet a “une communauté restreinte et peu de visibilité, il n’est pas mort et il y a du dév actif dessus”.

Tornado !

dimanche, septembre 13th, 2009

Le 10 août 2009, Facebook, le plus largement utilisé des réseaux sociaux, a racheté pour une somme avoisinant les 50 millions de dollars FriendFeed, un site de microblogging fait par d’anciens de chez Google.

Cette information en tant que telle n’est pas si intéressante, mais elle prend beaucoup de force quand c’est Facebook, un gros producteur de technologies open source, qui rachète un site fait par d’anciens de chez Google et donc utilisant Python comme langage de programmation (oui, vous vous souvenez, le meilleur langage du Monde !!!).

Le résultat de tout cela est la libération de Tornado, un serveur d’application web asynchrone écrit en Python. Les performances anoncées semblent impressionantes, très supérieures à celles du standard actuel pour les applis python en production Apache+mod_wsgi, et donc aussi à ce que peut faire TwistedWeb, le seul autre serveur web python asynchrone.

J’ai été mis au courant par la mailing list django-developers où une annnonce à été faite par Bret Taylor, et j’ai pu trouver par la suite l’avis de Glyph Lefkowitz, le papa de Twisted, une des rares personne très compétentes dans le domaine complexe et globalement mal maitrisé de la programmation asynchrone, alors que Dustin Sallings a déjà forké Tornado de manière à ce qu’il utilise Twisted (oui, vous vous souvenez, le logiciel libre c’est trop génial, ça bouge à mille à l’heure, aucune entrave à la création !).

Un benchmark, et puis un autre, et encore un autre.