Et le meilleur framework web Python est… Django !

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 souhaitait 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 job, un emploi, 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”.

Tags: , , , , , , , , , , ,

29 Responses to “Et le meilleur framework web Python est… Django !”

  1. Carl Chenet says:

    Billet très intéressant merci. C’est vrai que j’ai toujours eu l’impression d’un foisonnement des solutions dans ce domaine qui amène à se poser des questions lorsqu’on cherche une solution pérenne et solide pour, par exemple, un besoin professionnel. Alors qu’en fait la réponse semble claire, comme le plus souvent : la présence d’une communauté importante autour d’un logiciel bien pensé permet la pérennité et le développement contrôlé du projet.

  2. Carl Chenet says:

    Petit détail : il n’y a pas de lien pour Tornado : http://www.tornadoweb.org/

  3. Bon billet. À noter aussi des frameworks plus génériques tels que Twisted. Ils peuvent faire de très bon framework web. Toutefois, dans le cas de Twisted, la situation d’un point de vue web commence seulement à s’éclaircir.

  4. Quelques remarque sur pyramid:

    - on ne fait pas de sql à la main. SQLAlchemy s’appelle un ORM

    - on ne choisit pas un lanquage de template pour chaque vue. On choisit une manière de rendre une vue. Une même vue peut avoir des rendu différent celon des prédicat défini par l’utilisateur. Chaque rendu peut utiliser un moteur de template différent. C’est ce qu’on appelle de la souplesse, je crois

    - la component architecture est utilisé en interne pour des raisons de performance. Il n’est absolument pas nécessaire de savoir s’en servir pour utiliser le framework.

    Django et Pyramid ont des publics différent. De la à dire que l’un est meilleurs que l’autre, surtout avec les arguments énoncés… Ca relève du bon troll de base.

    • fgallaire says:

      - Dans le tutoriel c’est à la main. Bien sûr on peut utiliser SQLAlchemy, mais ce n’est pas intégré au framework (c’est-à-dire que ça ne fait pas le boulot qu’on attend justement d’un framework).
      - Une fonctionnalité inutile (pire que ça, qui casse tout espoir de développements réutilisables) et qui me fait écrire en plus (je déteste les efforts non nécessaires)
      - La component architecture choisie pour sa souplesse et sa modularité sans égal ok, pour ses performances je rigole.

      Django et Pyramid ont sûrement des publics différents, mais je reste dubitatif face au concept de framework pour les super bons programmeurs (i.e. ceux qui n’ont en fait pas besoin de framework !).

  5. - Pas celui que je connais: http://docs.pylonsproject.org/projects/pyramid/1.0/tutorials/wiki2/index.html

    - Inutile ? Ok, si tu veux faire autant de vue que de format de sortie, abstiens toi de faire des service web. Perso une seule vue pour rendre à la fois du html, du xml, du json, ça me va. Y a même des gens qui font ça avec django: https://bitbucket.org/david/djangorators/src/ce1d26b628a2/examples/

    - Le dispatching d’url est basé sur une registry implémenté en C

    • fgallaire says:

      Pourquoi faire simple quand on peut faire compliqué ? :
      “Pyramid Views Do Not Accept Arbitrary Keyword Arguments”

      • Ouais, c’est vrai. Pourquoi faire une multiplication dans une template quand on peut faire un templatetag de 20 lignes.

        Comme prévu, ça vire au troll de base.

        • fgallaire says:

          Pardon Gaël, mais avec la méthode Coué on peut arriver à tout, évoque sans raison le “troll” a chacun de tes commentaires et il finira peut-être par arriver…
          Pardon de lire la doc de Pyramid et d’évoquer un point de design suffisamment contestable pour qu’il soit expliqué et défendu dedans !

          • En titrant un post “Et le meilleur est…” On sait comment ça fini… Si je dis que Vim est meilleur qu’Emacs je déclenche le plus vieux troll du monde libre.

            Django est idéal quand tu peux utiliser les produit tierce de la communauté dans ton projet. Pyramid n’a pas son pareil pour construire une api RESTFull.
            Le design est différent, le public différent, la cible différente. Il n’y a pas de meilleur.

            Remarque que je n’avais pas cherché à descendre django, juste a remettre Pyramid à sa juste place. Pourtant bien des points de la conception de Django sont contestable. Sans parler de la gestion de sa communauté, même si ça a tendance à s’améliorer depuis peu. Mais ça, tu n’en parles pas.

            Pour conclure, j’ai bien aimé le retour d’expérience d’Andy McKay qui explique que django c’est bien, surtout quand tu l’utilises pas trop: https://github.com/andymckay/presentations/blob/master/confoo-2011/large-django.pdf
            C’est assez instructif.

            • fgallaire says:

              Plus que de “meilleur”, l’article parle de la mécanique de consolidation des projets libres, en prenant un exemple particulièrement riche et intéressant. Il y a des liens qui expliquent les critiques principales faites à Django (en particulier le monolithisme).
              J’ai une grosse critique non présente sur la lenteur de l’acceptation par les core dev du travail fait sur django-nonrel, car je consacrerai peut-être un article à ce sujet.
              Merci pour ton lien (et tes commentaires).

  6. Alfred says:

    Ces derniers temps je bosse sur des projets repoze.bfg avec ZODB et Chameleon comme moteur de templates et je peux vous dire que c’est l’enfer.

    Le plus gros problème c’est ZODB. C’est très facile de se tirer une balle dans le pieds avec les index vu que c’est à la charge de l’application de les maintenir comme elle peux en utlisant l’API mouvante de repoze.catalog. Si ce n’est pas l’application qui se trompe, ZODB sait très bien nous pourrir la vie tout seul grace à son méchanisme de verrou optimiste qui fait que de temps en temps une requêtre peut échouer. Ils ont même un paquet spécial pour ca qui rejoue une requêtre en cas d’échec, comme ca super l’utilisateur recoit deux mails de confirmation. Au niveau connectivité c’est également completement nul: deux applis avec des versions légèrement différentes des libs ZODB ne peuvent causer entre elles, obligé de coder un web service en urgence. Vous êtes sympa dans votre article quand vous dites que c’est une base de donnée objet en avance sur son temps. N’allez pas vous imaginer que vous allez stocker vos objets applicatifs tels quel. Au contraire il faut utiliser des objets bien précis tel que le PersistantMapping et le Folder sinon vos objets ne sont pas sauvés à moins d’écrire dans les attributs ésotériques tels que obj._p_changed. Il faut donc bien se conformer à un modèle de donnée distinct de celui de l’appli exactement comme avec SQL, la seule différence c’est qu’on enferme notre base de données dans notre appli, pas de partage avec d’autres languages ni même d’autres applis Python pour peu que les versions des package en jeux diffèrent légèrement, pas de réplication, pas de sharding, vive la modernité.

    Ensuite la ZCA. Aah la belle architecture à composant qui ne sert à rien à part vous compliquer la vie. Au départ franchement j’étais plein d’optimisme naif et je pensais que je finirais par en voir les avantages et je peux vous dire qu’après plusieurs mois de calvaire je n’en ai pas vu un seul, par contre c’est au quotidien que ce système kafkaien se met en travers de notre route et ralenti la livraison de fonctionalités que nos clients attendent. Ce n’est pas faute d’avoir lu de la doc (de mauvaise qualité) pourtant. Ce système n’est simplement pas intuitif et trop éloigné des préoccupations d’un développeur applicatif. Ce n’est pas vrai qu’il est utilisé uniquement en interne et qu’on peut l’ignorer. Lui il ne vous ignorera pas et viendra vous casser les bonbons à la première occasion.

    Enfin il y a Chameleon, franchement si vous avez un moment à tuer allez jeter un coup d’oeil à la doc, c’est très drole… quand on ne l’utilise pas. Le moteur comprends trois language distincts mais qui marchent ensemble, il est enfermé dans le carcan du XML ce qui donne des syntaxes à coucher dehors pour les attributs et l’obligation de tester deux fois une valeur pour pouvir faire un else. J’ai du utiliser une petite dizaine de langage de templates avant mais vraiment Chameleon remporte haut la main la palme de l’absurdité syntaxique. Attendez je ne vous ai pas dit le plus drole: impossilbe de réutiliser simplement des morceaux de templates, il faut passer par l’api Python, rendre les morceaux de templates et inclure le résultat. Je sais ca parait incroyable mais c’est vrai.

    Alors oui, quand j’ai un peu de temps libre pour faire du Django, c’est comme si je me baladais dans un parc fleuri par une belle journée de printemps avec des jeune filles qui me sourient à chaque courbe de l’allée. C’est doux, c’est simple, c’est beau.

    Vraiment le problème de tout ce qui vient de Zope c’est qu’au lieu d’aider au developement ca le rends infiniment plus difficile. Lorsque je travaillais avec Pylons, il y avait beaucoup de choses à faire soi même, mais c’est tout à fait différent que d’avoir à lutter contre quelque chose. C’est simplement une absence, un vide à combler, une opportunité d’apprendre. Bien sûr la productivité n’est pas au rendez-vous avec Pylons mais au moins on avance pas à reculons comme avec Zope, Repoze et toutes ces infamies.

    Je n’ai pas essayé Pyramid mais je pense que si on évite ZODB comme la peste et on s’équipe d’un moteur de templates digne de ce nom, on doit pas être loin de Pylons, ce qui n’est pas si mal.

    Une mention sur Tornado, le mini-Django super bien fichu, plein de bonnes idées et vraiment léger. Pas comme ces frameworks prétendument légers mais qui nécessitent l’installation de dizaines de dépendances à la rétro-compatibilité douteuse qui font qu’on ne sait jamais si l’appli va marcher quand on essaye de l’installer sur une nouvelle machine à moins d’avoir bien fait attention de coder en dur toutes les versions dans le setup.py.

    • Voila au moins une argumentation tirée d’une histoire vécue…

      Cependant la ZODB est bien en avance sur son temps. Elle existe depuis… 10ans ? Et c’est bien du NoSQL, non ? :) Cela dit c’est vrai que de nos jours c’est un peu obsolète par rapport au bases NoSQL récente.

      Personnellement je n’ai pas de problème avec Chameleon. J’aime bien qu’on me force à avoir du xml valide et j’aime bien pouvoir faire du python quand j’en ai besoin. Enfin savez vous qu’on peut utiliser la syntaxe ${var} au lieu des attributs xml ?

      Mais en effet, Akhet permet de créer un projet Pyramid dont la configuration utilise mako et sqlalchemy. Donc très proche de Pylons et loin de tous les “problèmes” cités.

      • Alfred says:

        Effectivement ${var} fonctionne dans les attributs. Je jurerais avoir essayé sans succès pourtant et je ne sais pas pourquoi notre base de code ne l’utilise pas du tout, sûrement une habitude issue des ZPT. En tout cas merci du tuyau ! Je suis d’accord sur le besoin de faire du python de temps en temps, mon préféré c’est Mako. D’ailleurs Tornado bien qu’il reprenne la syntaxe des templates Django est plus laxiste à ce sujet. Par contre je n’ai pas vu comment faire ça dans Chameleon au delà des expressions “python:” de TALES. Pour le XML je trouve ça moins lisible que les syntaxes spécifiques qui permettent de distinguer visuellement au premier coup d’oeil les instructions de template et le marquage, mais là c’est évidemment subjectif. Et tu fais comment pour générer autre chose que du XML, des balises bidons avec tal:omit-tag ? Et pour le HTML ? Parce que bon XHTML a quand même du plomb dans l’aile en ce moment. Et pour la réutilisation de morceaux de templates existants tu t’y prends comment ? Ici on a une classe python qui fait des get_template() et qu’on inclut dans le contexte de toutes nos templates. Je n’ai pas vu comment faire ça avec le langage de templates directement mais j’ai peut-être encore raté quelque chose.

        Sur le NoSQL, le mouvement est surtout né d’un besoin de scalabilité (réplication, partitionnement..), choses pour lesquels ZODB ne brille pas vraiment. À ce compte là dbm, les fichiers indexés du COBOL ou même le fameux Pick du Dr. Helios c’est du NoSQL aussi hein ;)

        • Georges Racinet says:

          Pour le langage de template, c’est une question de goût. Personnellement, mélanger du HTML avec une syntaxe complètement étrangère, ça m’a toujours
          semblé dégueu.

          Ne pas oublier qu’un des buts initiaux de ZPT, c’est d’être visible directement dans un navigateur, et même éditable par un éditeur HTML (bien sûr ça devient un voeu pieu quand on a des templates de macros en cascade comme on en trouve dans le monde Zope, mais moins en Pyramid justement)

          et bien sûr que NoSQL c’est un peu galvaaudé et que BDB, les fichiers indexés de COBOL (connais pas), ou des choses comme NNTP en font partie. Les gens du débutt des années 80 étaient forcés de faire du distribué asynchrone. Il y a eu un accident de l’histoire d’une dizaine d’années, pendant lequel « base de données » est devenul presque synonyme de SQL, voilà tout. C’est quand même assez courant en info d’utiliser des outils parce qu’ils sont ultra-répandus et standardisés (LAMP) et non parce qu’on a vraiment besoin de tout ce qu’ils fournissent.
          On réinvente la roue tous les 10 ans, j’ai arrêté de m’énerver à ce propos.

          Après, le reste c’est des débats sans fin

        • Tu n’est pas obligé d’utiliser “python:” C’est du python par défaut. Tu peux aussi utiliser du python dans une expression ${}

          Quand j’ai besoin d’autre chose que du xml, j’utilise mako que je préfère aussi à Chameleon. L’avantage de Chameleon est qu’il ne nécessite pas d’enregistrer des path et il est donc plus pratique pour écrire des plugins intégrable facilement. Comme pyramid_formalchemy

          Pour ce qui est de l’inscription de template, une option est d’utiliser cet événement: http://docs.pylonsproject.org/projects/pyramid/1.0/api/events.html#pyramid.events.BeforeRender

    • Carl Chenet says:

      Je recommande également Tornado, qui après des débuts assez laborieux lors de “libération” par Facebook (plus aucune activité pendant plusieurs mois) est aujourd’hui mis à jour et évolue rapidement. En plus vous pouvez facilement l’installer sur votre Debian :p

      • fgallaire says:

        Tornado est excellent, très léger/rapide, et a la qualité rare de faire de l’asynchrone, cependant ce n’est pas un “full-stack” framework (pas d’ORM).

  7. Eric Dussart says:

    Expédier WEB2PY par une simple phrase : “Alors bien sûr vous pouvez aussi utiliser web2py” …
    Web2py a démarré en 2007 et connait une progression très importante (voir CMS sur le site Python). Il suffit de rechercher les nombreuses comparaisons existantes (Danjgo / Web2py) pour se rendre compte que Django n’est pas encore seul. Pour ma part, j’ai choisi Web2py et je ne le regrette pas.

    • marco says:

      Tout a fait d’accord.
      Je pense que web2py a sa place dans les frameworks web python “majeurs”. Il n’est peut-être pas aussi raffiné que Django (que j’apprécie également beaucoup), mais c’est celui qui me permet d’être le plus efficace dans la création de mes outils persos et pro (souplesse d’utilisation, courbe d’apprentissage, productivité…).

      Bisous à tous les pythonistes (et aux autres aussi)

  8. Poincare says:

    J’ai choisi Django justement parce qu’il intègre tout. Son homogénéité est très agréable. Je comprends cela dit que certains préfèrent réutiliser des projets existants.

    +1 pour intégrer django-nonrel dans Django :)

  9. Encolpe says:

    Je suis assez d’accord avec Gaël sur le choix du titre. Et de plus cantonner Zope 2 à CPS c’est très réducteur. Cela fait longtemps que les développeurs Zope 2 font aussi du django et du pyramid. Cela dépend des contraintes du projet.

    Pour CPS, il y avait un bonne communauté de personnes refusant de contribuer. Zope 3 n’avançait pas et plusieurs clients on demandé un équivalent de CPS en J2EE. De mon point de vu c’est un échec des communautés Python et Zope, et un succès de Nuxeo. D’ailleurs, nous attendons toujours des programmes de certification (http://www.mail-archive.com/django-users@googlegroups.com/msg108596.html)

    Pour ce qui est du problème SQL/NoSQL le problème vient souvent d’une méconnaissance des modèles sous-jacent : http://www.christian-faure.net/2011/04/18/sens-et-enjeux-des-modeles-de-stockage-et-dacces-aux-donnees/
    La ZODB n’est pas une base de données Not Only SQL (NoSQL) dans l’acception générale des développeurs :
    - Son stockage être fait sur une base SQL (Oracle, MySQL, PostgreSQL) ou directement dans le système de fichiers.
    - Il n’y a pas de système de requêtage, juste un accès à des objets.
    - Les indexes sont à gérer manuellement et il est possible de créer des ensembles disjoints d’indexes.

    Tout cela pour dire que chacun voit midi à sa porte et que la force du logiciel libre est d’avoir autant de fuseaux horaire de de développeurs.
    Personnellement j’utilise ed et Wing IDE car vim, emacs et PyDev me donnent des boutons.

  10. [...] 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 [...]

  11. G-rom says:

    J’aurai juste voulu attirer votre attention sur Nagare (http://nagare.org) qui m’a permit de faire mes gammes en python et que je trouve très intéressant !

  12. alex says:

    Bonjour,
    très intéressant ce billet. Pour ceux qui pourraient être intéressés nous recherchons un développeur confirmé en Python (framework Django) dans le cadre de l’optimisation du site http://www.myapi.fr . Myapi.fr est le site d’achats groupés de billets tous loisirs (concerts, festivals, théâtre, parcs d’attraction..) et de vêtements de grandes marques (diesel, guess, kaporal, ck..). N’hésitez pas à nous contacter via le formulaire de contact sur notre site ou nous laisser votre CV, lettre de motivation et contact téléphonique à contact@myapi.fr. Bonne journée.

  13. tonthon says:

    Un titre facil pour prétendre à l’omniscience.

Leave a Reply