Depuis quelques jours le créateur de Python fais trembler la communauté toujours grandissante des frameworks Web en Python.
Intro:
http://www.artima.com/weblogs/viewpost.jsp?thread=146149
http://www.artima.com/weblogs/viewpost.jsp?thread=146503
Django c'est bien;
http://www.artima.com/weblogs/viewpost.jsp?thread=146606
XML c'est mal:
http://www.artima.com/weblogs/viewpost.jsp?thread=146647
C'est assez bien étudié dans l'ensemble, avant de lire les commentaires allez lire ici pour voir le résumé :
http://blog.delaguardia.com.mx/index.php?op=ViewArticle&(...)
Bon par contre je suis pas vraiment d'accord avec lui; d'abord parce qu'il préfère Django que je ne trouve pas terrible, et parce que son insistence contre le XML est mal défendue. En gros son seul argument est qu'il ne veut pas fermer les balises p et mettre les attributs entre guillemets... Bienvenue en 1995 !
Du coup son choix de templates se retourne vers ca:
{%if name%}
Hello {{name}}
{%else%}
Hello There
{%endif%}
Au secours !! Autant faire du PHP franchement.
Journal Guido juge le monde web Python
1
fév.
2006
# Et mod_python
Posté par Pinaraf . Évalué à 5.
Je me demande pourquoi personne n'en parle. L'écriture de templates est très simple avec PSP (Python Server Page).
[^] # Re: Et mod_python
Posté par Anonyme . Évalué à 1.
# à propos de Django,
Posté par nicolasr . Évalué à 2.
[^] # Re: à propos de Django,
Posté par Thomas Hervé . Évalué à 3.
On vient donc au problème de fond: ils ne considérent pas l'existant. En gros ils refont tout eux-mêmes (voir ici : http://blogs.nuxeo.com/sections/blogs/fermigier/2006_01_22_u(...) ), sans regarder ce qui existe, et ne font pas vraiment mieux (ce n'est que mon avis). Du coup quand tu commences un projet avec Django tu utilises tout leurs outils, et tu ne peux pas vraiment en sortir ou choisir une solution qui te convient mieux pour un élément spécifique. De ce côté TurboGears est beaucoup intéressant (même si il ne manque pas de défaut).
Enfin le problème de fond est qu'il n'y a pas de solutions émergeantes qui aie tout les avantages. C'est pourquoi Django séduit je pense: ca marche, tout simplement.
[^] # Re: à propos de Django,
Posté par herodiade . Évalué à 6.
Il note que la plupart des composants ne sont pas (ou sont peut) interchangeables, à l'exceptions des seules parties reposant sur WSGI: pas d'API unifiée pour les framework d'auth, de templating, de persistance, de réécriture d'url etc. Par ailleur il note que les gros framework sont souvent documentés pour une utilisation "tout en un" (pas de tuto sur l'utilisation spécifique d'un composant précis).
La conséquence c'est qu'il faut choisir un environement complet ou rien, meme si, ce qui nous conviendrai le mieux serai par ex. une utilisation combinée du moteur de template de django, de l'ORM sqlobject, de l'interface avec le serveur web WSGI, Twisted pour les accès soap/rpc/webservices, Route pour la réécriture d'url, une combinaison ldap/coockie/sessions pour l'auth, mochikit pour ajax...
Ce manque de modularité / interopérabilité / documentation est d'autant plus dommage qu'aucun framework ne peut prétendre couvrir tout les besoins/priorités des developpeurs, et que tous sont pensés à partir d'idées/d'attentes pré-conçues. Cf. le commentaire de GvR sur RoR par ex., ou bien sur les moteurs de templates conçus pour génerer du xml/html mais pas du texte brut, sur les couches de persistances supposant un accès sql à l'exclusion d'une serialisation directement dans des fichiers (ou pire: qui imposent un schema préderminé de base, donc incomatible avec une base déjà existante) et surtout sur l'authentification/authorisation (à mon avis le pire problème, parce que la gestion des utilisateurs est vraiment une problèmatique au cas par cas selon l'entreprise, ldap, kerberos, sql, unix pwd, ... les possibilités sont nombreuses).
Je trouve d'autre part que ce débat à mis à jour une incroyable multiplicité de solutions (frameworks complets ou composants), entre lesquelles il devient très difficile de choisir (d'autant que le choix est généralement décisif, bloquant, et sans retour, vu le manque d'interopérabilité). Le fait que GvR pose sa question est la preuve qu'il y a un problème de lisibilité dans cet ensemble de framework (et le fouilli de réponse prouve combien il est difficile de s'y retrouver).
Il faudrait des mois pour évaluer ces différents framework (ou composants plus ou moins compatibles) web: turbogears, zope/plone, django, web.py, cheetah, myghty, stan, Kid, pylons, Paste, Nitro, cherrypy, rhubarbtart, route, karrigel, web.py, quixote, webware, skunkweb, subway, aquarium, webstack, nevow, ...
C'est énorme !
Pourquoi autant de developpeurs python écrivent (et publient !) leur propre framework web ? et, par contraste, pourquoi si peu de travail et documentation sur l'intéropérabilité / l'unification ?
GvR note aussi que l'utilisation des gros frameworks combinés est beaucoup plus longue et difficile qu'il n'y parrait (cf. son commentaire: RoR permet de coder vite .. uniquement si on maitrise déjà parfaitement ruby, le sql, le javascript, et tt les différents composants du framework, ou sa réponse a Lunh: tu t'en sort facilement avec django parceque tu es expert python, celementree etc.).
Est-ce qu'un bon jeux de petites libs, à l'API stable et bien documentée, sous tests unitaires indépendants, réutilisables, combinables entres elles à volontée et des tutos sur la façon de les combiner ne serait pas mieux que d'énormes usines à ga^W^W monuments comme zope ou django ? (c'est ce qu'on fait perl -avec cpan - et php avec pear, et non, pypy n'est pas du même ordre).
J'espère que GvR sera entendu lorsqu'il appelle à faire des PEP equivalents à WSGI sur les autres composants des frameworks web (l'auth, les templates etc).
[^] # Re: à propos de Django,
Posté par Thomas Hervé . Évalué à 3.
Cela imposerait une standardisation à l'extrême. Aujourd'hui comme standards on a en gros WSGI et DBAPI. Le reste est encore flou, mais ce n'est pas vraiment spécifique à Python. Cela demandera un travail dingue de penser une interface d'authentification unique, qui répondent à la multiplicité de l'essence.
Pourquoi autant de developpeurs python écrivent (et publient !) leur propre framework web ?
C'est à mon avis lié à la population qui compose la communauté Python. De bons codeurs, pros du NIH, et qui n'ont pas de solution évidente à disposition. En comparaison, si je devais faire une appli en Java il y aurait 80% de chances que j'utilise Struts, parce c'est le choix le plus répandu et que mes connaissance de Java sont trop limitées pour que je réfléchisse plus loin.
Au final si il y a autant de frameworks, c'est qu'il est très facile d'en faire un avec Python. On ne peut pas vraiment dire que ce soit un défaut du langage !
et, par contraste, pourquoi si peu de travail et documentation sur l'intéropérabilité / l'unification ?
Parce que comme dans toute communauté il est plus facile de coder que de documenter :).
Est-ce qu'un bon jeux de petites libs, à l'API stable et bien documentée, sous tests unitaires indépendants, réutilisables, combinables entres elles à volontée
Un bon nombre des composants que tu cites sont indépendants et des briques unitaires : kid, sqlobject, stan, mochikit, route, paste, cheetah, voire cherrypy. Et ces briques progressent beaucoup à l'heure actuelle, c'est d'ailleurs la raison qui me fait douter de Django et plus croire en TurboGears.
# Et le else aussi
Posté par Nicolas Évrard (site web personnel, Mastodon) . Évalué à 2.
Et pourtant:
<tag-if cond="toto == 'tata'">
<tag-else />
<tag-if />
Ça ne me parait pas insurmontable ... Verbeux sûrement mais quand on doit écrire du xhtml ou de l'html on doit écrire des tags alors ce que j'en dis hein.
Par contre j'aimerai bien savoir ce qu'il pense de cherrypy car il me semble qu'il préférerait ce genre de truc à framework complet (et puis il pourrait utiliser le langage de templating qu'il veut).
[^] # Re: Et le else aussi
Posté par Pinaraf . Évalué à 2.
<xsl:choose>
<xsl:when test="condition1">
Cas 1
</xsl:when>
<xsl:when test="condition2">
Cas 2
</xsl:when>
<xsl:otherwise>
Sinon
</xsl:otherwise>
</xsl:choose>
[^] # Re: Et le else aussi
Posté par micha_mosk . Évalué à 1.
[^] # Re: Et le else aussi
Posté par hiphopmomo . Évalué à 3.
ya une balise xsl:if en XSLT, mais elle n'a pas de else.
Et ya une balise xsl:choose qui accepte des balise xsl:when et une balise xsl:otherwise => c'est plus un switch case qu'un if then else.
# Hey
Posté par cho7 (site web personnel) . Évalué à 4.
Perso j'aime beaucoup beaucoup, même si ces gorets de chez cherrypy n'ont pas assuré la compatibilité avec les anciens packages < 2.1 et que les 3/4 du wiki officiel montre encore des bouts de code de version 2.0 !
# Ce qui m'interpelle
Posté par golum . Évalué à 6.
On, imagine qu'ils vont le lâcher sur des killer features de Python, pour soutenir PyPy, pour creer de nouveaux proto d'agents en python,ben non.... tout ca pour lui faire faire un portail Web.
J'avoue que leur stratégie me dépasse.
[^] # Re: Ce qui m'interpelle
Posté par Boa Treize (site web personnel) . Évalué à 3.
Par ailleurs Google n'a rien à dire sur le travail que Guido fait pour Python, et de mémoire il y passera la moitié de son temps.
Enfin, malgré tout le respect que je dois à Guido, il y a de grandes chances qu'il ne soit qu'un employé "normal" chez Google, qui ne manque pas de grosses pointures.
# Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
# Twisted se démarque ?
Posté par Thomas Hervé . Évalué à 1.
http://glyf.livejournal.com/51057.html
QOTW : "J2EE is the Big Mac here"
# Python et ouebe --> Karrigell
Posté par lolop (site web personnel) . Évalué à 3.
Après, les gouts et les couleurs...
Accessoirement, c'est made in france (bon world-contribution comme tout bon soft open-source).
http://karrigell.sourceforge.net/
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.