Journal Guido juge le monde web Python

Posté par .
Tags : aucun
0
1
fév.
2006
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.
  • # Et mod_python

    Posté par . Évalué à 5.

    J'ai du coder ce week end une application web avec mod_python, et j'ai trouvé ça vraiment agréable à utiliser, simple et rapide.
    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 . Évalué à 1.

      En effet, modpublisher + psp est d'une efficacité redoutable, et en plus c'est propre sans faire d'efforts ...
  • # à propos de Django,

    Posté par . Évalué à 2.

    tu lui reproches quoi exactement ? je le regarde de plus en plus et il m'a l'air assez terrible malgré tout.
    • [^] # Re: à propos de Django,

      Posté par . Évalué à 3.

      Différents choses me génent. D'abord le moteur de templates ne me convient pas (l'exemple du sujet vient de là). C'est quand même un facteur important. De même leur ORM n'a rien d'extraordinaire (euphémisme).

      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 . Évalué à 6.

        Fondamentalement, le manque de modularité et 'interopérabilité des composants des divers framework est ce dont se plaint GvR, et je trouve sa remarque très pertinente.

        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 . Évalué à 3.

          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...

          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 (page perso) . Évalué à 2.

    Ce qu'il n'aime pas aussi c'est le fait qu'il serait difficile de faire un else avec un langage basé sur du xml.

    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 . Évalué à 2.

      Sinon y'a la "méthode" utilisée en XSLT. En XSLT y'a un if mais pas de else. Donc une solution :
      <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 . Évalué à 1.

        Et le <xsl:otherwise>, ce n'est pas un else?
        • [^] # Re: Et le else aussi

          Posté par . Évalué à 3.

          pas vraiment. Enfin, pas directement.

          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 (page perso) . Évalué à 4.

    Mais que penser du couple cherrypy + cherrytemplate ?

    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 . Évalué à 6.

    c'est que Google embaûche une sommité, et qu'ils ont dû certainement mettre la main à la poche poyur ce faire.
    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 (page perso) . Évalué à 3.

      Quand tu embauches quelqu'un, tu ne le lances pas tout de suite sur un gros projet vital, mais tu lui fais faire un galop d'essai (et une appli utilisée par la plupart des employés Google, c'est pas rien non plus).

      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 . Évalué à 4.

    Ce commentaire a été supprimé par l'équipe de modération.

  • # Twisted se démarque ?

    Posté par . Évalué à 1.

    Pour le plaisir, un post avec tout plein de choses intelligentes :

    http://glyf.livejournal.com/51057.html

    QOTW : "J2EE is the Big Mac here"
  • # Python et ouebe --> Karrigell

    Posté par (page perso) . Évalué à 3.

    C'est pour le moment l'outil le plus sympa que j'ai pu trouver pour faire des sites dynamiques avec Python. Je trouve les autres outils extrèmement lourds et peu dans l'esprit de Python.

    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/

    Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.