# Développement web python et frameworks, tour d'horizon début 2007

Un article intitulé « Python web development and frameworks in 2007 » très intéressant que j'aurais aimé traduire fait le bilan sur le développement web python et ses principaux frameworks, de web.py à Zope, en passant par Django, Pylons et TurboGears. J'ai appris de nombreuses choses donc je vous invite à aller le lire sur place mais c'est vrai que c'est assez long donc en voici un résumé accompagné de mes commentaires.

Rappel préliminaire : alors que David H. (principal développeur de Ruby on Rails) se moque gentiment du nombre de frameworks python assez paradoxal compte tenu de la maxime de Python : There Is Only One Way To Do It (en opposition à Perl), l'auteur de l'article rappelle que la diversité appelle l'émulation (et le choix pour les utilisateurs) et que la situation actuelle donne raison à Python compte-tenu du manque de réactivité dans le développement de Ruby on Rails. Je ne sais pas où en est le développement actuel de RoR donc je ne peux pas commenter cette affirmation même si je soupçonne un certain parti pris... quelqu'un pour confirmer/infirmer ?

Pour commencer, l'auteur fait le point sur les deux solutions que l'on peut considérer comme étant aux antipodes du développement web python : Zope et web.py. Zope a longtemps été la seule solution pour faire du web sérieusement en Python et souffre (malheureusement ?) de l'image d'usine à gaz qui la poursuit depuis l'arrivée des « nouveaux » frameworks web. Ce n'est pourtant pas une solution à rejeter pour certaines tâches car de nombreux composants sont disponibles et malgré une courbe d'apprentissage assez raide, la tendance actuelle est à sa simplification.

À l'opposé, web.py est quasiment l'anti-framework. Ironiquement, c'est le premier framework que j'ai découvert (probablement grâce à Simon) et qui m'a fait entrevoir l'étendue des possibilités offertes par Python dans le développement web. À l'origine, un seul fichier était nécessaire pour faire tourner une application, aujourd'hui ce framework a évolué mais il est toujours aussi simpliste/minimaliste. Il est donc à mon avis déconseillé pour les développements conséquents qui seront plus rapidement réalisés via des frameworks permettant d'avoir des raccourcis à tous les niveaux. En revanche, pour comprendre comment fonctionne un framework web dans ses moindres rouages, il y a difficilement mieux (lire auparavant l'excellent article de Joe Gregorio peu aider).

## Django : le tout en un fonctionnel

Je ne sais pas s'il est nécessaire de vous rappeler l'idéologie sous-jacente car j'en ai déjà parlé ici mais en gros il s'agit d'avoir un ensemble de composants cohérents entre eux, autant dans leur fonctionnalités que dans leur documentation. Tout a donc été écrit from scratch (argument supplémentaire, au début des développements les bibliothèques actuelles n'existaient pas) pour arriver à la récente version 0.96 actuelle.

Le gros avantage de Django c'est sa communauté importante (ici l'annonce de Guido y est aussi pour quelque chose à mon avis) et sa documentation (c'est quasiment un des buts initial donc ça semble normal).

Les inconvénients soulevés ne sont pas forcément tous valables à mon avis mais pour ceux qui sont indiscutables, concernent l'impossibilité réelle d'utiliser d'autres briques Python que celles définies par défaut. L'exemple donné est celui de SQLAlchemy et les arguments donnés sont bons : la branche ouverte pour gérer ce cas végète (comme beaucoup d'autres d'ailleurs).

Les vues génériques et l'administration auto-générée finissent toujours par décevoir, ce qui est logique étant donné la manière dont c'est mis en avant dans la documentation (heureusement que la situation est clarifiée dans le livre).

Il manque un dépôt centralisé d'applications. Django snippets est un excellent début en ce sens mais il faudrait pouvoir déposer des applications complètes aussi. Pour l'instant ces ressources sont éparpillées un peu partout... edit du lendemain : c'est en cours de réflexion.

Le manque de réactivité de la part de l'équipe de développement est soulevé et je suis assez d'accord sur ce point (plusieurs de mes mails sont restés lettres mortes sur la liste de diffusion). La situation est en cours d'évolution avec l'élargissement de l'équipe et c'est une bonne chose.

En conclusion, Django est tout de même un excellent framework qui a le mérite d'être fonctionnel maintenant et dont les récentes améliorations (newforms) sont prometteuses. Je ne m'étends pas plus sur django mais de nombreux points sont évoqués, preuve que l'auteur sait très bien de quoi il parle, autant pour les avantages que pour les inconvénients.

## Pylons : le framework à la carte

La philosophie de Pylons est à l'opposé de celle de Django, il s'agit de laisser le choix à l'utilisateur à chacun des niveaux pour l'utilisation de la bibliothèque existante qui lui convient. Par défaut, le framework ressemble beaucoup à Ruby on Rails et si vous souhaitez essayer Python en connaissant RoR, c'est le framework qu'il vous faut.

Le gros avantage de Pylons réside donc dans sa capacité d'adaptation, un peu à la sauce UNIX : laisser le choix à l'utilisateur en proposant des utilitaires simples que l'on peut enchaîner via des pipes. Par ailleurs, il est à noter que le principal développeur est apparemment accessible ce qui est toujours intéressant.

Le problème de pouvoir utiliser autant de briques est le manque de consistance de la documentation. Et même le meilleur des frameworks est inutilisable si l'on ne sait pas s'en servir (bon ok, j'exagère un peu ;-)).

Les composants fournis par défaut sont en train de changer pour fournir une meilleure base de développement. En particulier Toscawidgets, développé par l'équipe de TurboGears, mais aussi Mako pour les templates.

Quoi qu'il en soit, Pylons est conceptuellement vraiment intéressant et sera probablement à moyen terme une solution des plus alléchantes, surtout si la réutilisation d'applications venant d'autres frameworks devient possible. Aller vers une inter-opérabilité en ce sens serait une petite révolution.

## TurboGears : un framework pour les unir tous et...

La philosophie de ce framework est de prendre les meilleurs composants Python existants et de mettre la glu permettant de les lier pour arriver au framework optimal. L'idée est très bonne mais je ne suivais plus depuis quelques temps le développement de ce framework (on peut difficilement tout suivre, heureusement qu'il y a de tels articles récapitulatifs !). J'ai été vraiment très surpris d'apprendre la tournure prise par son développement.

Le concept est très bon mais et c'est là où TurboGears a échoué, il ne faut pas se tromper lorsque l'on choisit les composants initiaux, au risque de devoir tout recommencer. Et c'est ce qui arrive apparemment à ce framework, ce qui me cause un peu de soucis pour le projet actuel de Guillaume par exemple...

D'après ce que j'ai pu comprendre, la version actuelle (1.0) est gelée en attendant le développement de la v2 qui devrait voir quasiment l'ensemble des composants changés (soit de version, soit d'orientation). C'est un choix qui est difficile à prendre et qui annonce un long hiver pour TurboGears, ce qui se reflète dans le désintéressement de la part de sa communauté apparemment. Je rejoins l'avis de l'auteur dans l'idée d'un rapprochement avec Pylons qui laisserait le choix de changer aisément à l'utilisateur et qui se baserait sur certaines des bibliothèques développées spécifiquement pour TurboGears comme Toscawidgets.

En tout cas j'en reviens pas d'un tel revirement de situation, j'espère que le projet pourra tout de même se relever car c'était vraiment bien parti et ça avait dopé, entre autres, le buzz autour des frameworks web Python au début de l'année dernière. Il était alors aussi populaire que Django !

## Conclusion

Django et Pylons sont deux solutions ayant fait des choix différents dans l'implémentation de leur framework mais qui sont toutes deux actuellement fonctionnelles. Le choix entre les deux se fera à mon avis en fonction de votre expérience et de votre propre avis sur leur philosophie.

Comme je le disais précédemment, le développeur est aujourd'hui confronté au difficile dilemme d'utiliser un framework adapté à ses besoins sans pouvoir connaître tous les frameworks existant en détail car ils sont trop nombreux et évoluent trop rapidement. Ne serait-ce que pour être compétent sur Django, Pylons et Ruby on Rails par exemple, c'est mission quasi-impossible... et je ne parle même pas des frameworks PHP !

Quelle solution alors ? Il ne reste plus que les drogues dures je crois Apprenez ce qui vous plaît. Vous travaillez pour un client, ok. Mais vous travaillez dans le développement web aussi pour le « fun » que ça procure de coder, n'oubliez jamais ça. Prenez du plaisir dans votre travail et arrêtez de vous prendre la tête sur le choix du framework, si vous travaillez deux fois plus rapidement car ce que vous faites vous plaît, le client sera toujours content. Et vous aussi :-).

### Articles peut-être en rapport

- Sortie de Django 1.0, une année de nouveautés
- Des vacances et des liens
- Une solution pour faciliter la conception d'applications web RESTful avec Django

### Commentaires

NiKo le 31/03/2007 :

Ta première conclusion me rappelle un commentaires à moua :D
www.biologeek.com/journal...

bolo le 31/03/2007 :

Je suis assée etonnée de son affirmation. Alors que la version 1.2.3 vient de sortir.
Se sont des querelles de clochers le meilleur framework web avec qui tu serras le plus productifs

Bader le 31/03/2007 :

Hmm, "était aussi populaire que Django" ?
Je pense que Turbogears a toujours été davantage populaire que Django quoi que tu en dises...
Pour trouver django je cherche "django python" sur google, pour turbogears "turbogears" et google.com/trends me dit que turbogears est légèrement plus populaire que Django. google.fr/trends?q=django...
Et ce que tu dis pour Pylons:
«il s'agit de laisser le choix à l'utilisateur à chacun des niveaux pour l'utilisation de la bibliothèque existante qui lui convient.» s'applique également à TurboGears.
En effet avec TurboGears c'est par l'installation d'egg que le système se construit. Le système de template par défaut peut être remplacé par un autre tant que le plugin pour a été écrit, ça n'a rien de sorcier. Et d'ailleurs il existe plusieurs systèmes de template qui peuvent remplacer Kid (celui par défaut). Idem pour SQLObject. L'intégration de SQLAlchemy est plus complexe puisque ce dernier offre moins de "magie", il faut coder une glue pour le rendre aussi simple d'utilisation.
Il n'y a pas eu d'erreurs dans le choix des composants comme tu le laisses entendre, seulement aujourd'hui émerge des composants encore plus intéressant. (SQLAlchemy, genshi et CherryPy3 n'existait pas au lancement de turbogears).

David, biologeek le 01/04/2007 :

@NiKo : oui :-)
@bolo : je suis bien d'accord.
@Bader : google trends est loin d'être représentatif je trouve. Se baser sur le nombre d'inscrits aux mailing-lists est plus intéressant :
Django : groups.google.fr/group/dj...
Turbogears : groups.google.fr/group/tu...
Après ce que je dis pour Pylons/TG c'est surtout un résumé du billet en question.

Alex Conrad le 05/07/2007 :

pour votre information, l'émergeant web framework Pylons va désormais servir de base de développement pour le futur TurboGears 2.0.
Voici quelques liens (en anglais)
Annonces:
cleverdevil.org/computing...
groups.google.com/group/t...
Voici le lien de la discussion suite à l'annonce (sur pylons-discuss):
groups.google.fr/group/py...

David, biologeek le 05/07/2007 :

Tout à fait, merci pour les liens, j'avais placé l'info sur ma home (dans la rubrique Ailleurs) avec les liens suivants :
www.blueskyonmars.com/200...
www.oreillynet.com/onlamp...
mais merci pour les nouveaux liens, c'est vrai qu'il fallait le préciser sur ce billet.