Sortie de Django 1.4

Posté par  (site web personnel) . Édité par patrick_g, baud123, claudex, Florent Zara, Tobu et detail_pratique. Modéré par Florent Zara. Licence CC By‑SA.
Étiquettes :
40
27
mar.
2012
Python

Vendredi matin, un an après la 1.3, est sortie la version 1.4 du framework Web Django, écrit en Python.

Ce framework, basé sur un concept Modèle-Template-Vue (MTV, à rapprocher du MVC), est conçu pour le développement rapide et reprend la plupart des grands principes de Python (« Explicit is better than implicit », notamment), ce qui en fait la plate-forme de développement Web idéale pour les perfectionnistes sous pression.

De plus en plus de sites utilisent Django (par exemple, 20minutes, Libération.fr, Disqus, Century21, convore, instagram, threadless…) pour sa flexibilité et pour le nombre d’applications Django réutilisables, qui ne cesse de croître.

Je vous propose de découvrir les quelques nouveautés que vous offrent les développeurs Django et toute la communauté.

Sommaire

Tout comme Ruby on Rails, la flexibilité de Django en fait une bonne alternative à mi‑chemin entre le CMS et le langage pur pour la conception d’applications Web agiles.

Cette version marque l'abandon de la compatibilité avec Python 2.4, et l'adoption d'un plan pour la compatibilité avec Python 3: la prochaine version abandonnera Python 2.5, et sera compatible à la fois avec Python 2 (2.6 et 2.7), et Python 3 (sans doute la 3.3). Un port Python 3 expérimental est déjà disponible, mais l'adoption de ce support dans Django devrait donner le signal du départ à tout le paysage logiciel qui l'entoure.

Voici la traduction sommaire de quelques points que vous trouverez dans les notes de version :

Notes de version

Les principales nouveautés

Tous ces changements se sont faits dans un respect de la politique de stabilité d’API. C’est pourquoi Django 1.4 apporte son lot d’éléments mis en dépréciation.

Cependant, certains changements ne sont pas rétro‑compatibles et il faut consulter la documentation relative à ce sujet.

Les autres changements

  • Gestion de WSGI: Un fichier wsgi.py est désormais fourni à la création d'un projet.
  • Analyse HTML pour les tests : Fonctions pour analyser l'HTML et améliorer les recherches de correspondance
  • Tous les templates et l'interface d'administration utilisent désormais le doctype HTML5.
  • L'interface d'administration permet maintenant de créer des filtres personnalisés et autorise le tri sur plusieurs colonnes.
  • Une infrastructure de signature cryptographique des cookies est mise en place.
  • La fonction de form wizard a été réécrite.
  • Dans django.core.urlresolvers, une version paresseuse de reverse a été mise en place sous le nom de reverse_lazy.
  • Nouveau filtre truncatechars qui permet de tronquer une chaîne de caractères à la longueur spécifiée.
  • Une option de protection contre le clickjacking est maintenant disponible.
  • La protection contre les attaques de type CSRF (Cross-site request forgery) est renforcée.
  • Django 1.4 permet maintenant de filtrer les informations sensibles dans les rapports d'erreur.
  • Support IPv6 étendu.

Rétro‑compatibilité

Notez que la liste n'est pas exhaustive et qu'il faut donc impérativement consulter les notes de version avant toute mise à jour.
Parmi cette liste, citons :

  • Au vu de son impact dans le nouveau mécanisme de sécurité, le paramètre SECRET_KEY est maintenant requis.
  • L'accès aux fichiers statiques de l'espace d'administration se fait désormais par django.contrib.staticfiles et ADMIN_MEDIA_PREFIX devient inutile
  • La liste des navigateurs supportés par l'interface d'administration s'amenuise (bye bye IE6)
  • CSS class names in admin forms
  • Des problèmes peuvent survenir si vous passez directement de la 1.2 à la 1.4 à cause du changement sur la signature des cookies et sessions
  • Changement dans la sérialisation des temps avec JSON
  • Les exceptions MySQLdb.OperationalError sont remplacées par django.db.utils.DatabaseError
  • La protection CSRF a été étendue aux méthodes PUT et DELETE
  • Les diverses possibilités d'appel au décorateur cache_page ont été simplifiées.
  • La version minimum de PostgreSQL qui est requise est la 8.2.
  • Les Request exceptions sont maintenant enregistrées par défaut, et ce quelque soit la valeur de DEBUG.
  • Les fonctions présentes auparavant dans le module django.conf.urls.defaults sont maintenant présentes dans le module django.conf.urls.
  • La fonction django.contrib.databrowse est dépréciée car non utilisée.
  • La syntaxe des attributs is_safe et needs_autoescape a été modifiée.
  • La recherche des INSTALLED_APPS via des caractères joker a été supprimée (non utile et peu conforme aux pratiques Python).
  • L'attribut HttpRequest.raw_post_data a été renommée en HttpRequest.body
  • La correction d'un bug sur django.contrib.sitemaps a des conséquences en terme de performances. Il faut utiliser l'infrastructure de cache pour contrer cette régression.
  • La fonction django.core.management.setup_environ est dépréciée car jugée inutile (il est possible d'utiliser django.conf.settings.configure à la place).
  • La fonction django.core.management.execute_manager est dépréciée car elle est redondante avec django.core.management.execute_from_command_line.

Malgré la mise en place du nouveau template de projet par défaut et les deux derniers changements cités, l'ancien fichier manage.py reste utilisable. Cependant, il enverra un avertissement DeprecationWarning à partir de la version 1.5, donc ne perdez pas de temps pour mettre à jour ce fichier.

De manière générale, la dépréciation d'une fonction dans Django suit la chronologie suivante:

  • Django 1.4 : PendingDeprecationWarning : avertissement silencieux qui peut être affiché via l'option « -Wd » de l’interpréteur.
  • Django 1.5 : DeprecationWarning : avertissement visible.
  • Django 1.6 : retrait.

Communauté francophone

Toutes les bonnes volontés sont demandées pour faire vivre le site de la communauté francophone de Django. Rendez‑vous sur la liste de diffusion que vous trouverez sur le site, ou mieux : passez nous voir sur le canal IRC « #django-fr » de Freenode.

DjangoCong

Nimage

Le 14 et 15 avril se déroulera près de Montpellier (Carnon-plage) la DjangoCong, rencontre de la communauté de développeurs Django francophones.
Il est encore possible d’aider dans cette aventure la toute jeune association Django-fr. Les niveaux de sponsorisation sont les suivants :

  • 200 € : poney motivé
  • 400 € : poney généreux
  • 37 000€ : poney président

En devenant sponsor, vous serez mentionné dans les communications autour de l’évènement, ainsi qu’en début et fin d’évènement.

NdA : merci à Tobu, detail_pratique et patrick_g pour l’aide apportée à la réalisation de cette dépêche.

Aller plus loin

  • # Re: Python—Sortie de Django 1.4

    Posté par  (site web personnel) . Évalué à 4.

    Merci pour cette depeche detaillée.

  • # linuxfr

    Posté par  . Évalué à 10.

    De plus en plus de sites utilisent Django (par exemple, 20minutes, Libération.fr, Disqus, Century21, convore, instagram, threadless…) pour sa flexibilité et pour le nombre d’applications Django réutilisables, qui ne cesse de croître.

    À quand linuxfr en django ?!

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: linuxfr

      Posté par  . Évalué à -2.

      Ce n'est pas près d'arriver à mon avis:
      - Ils viennent de migrer à RoR. Ce qui doit déjà être un gros travail.
      - Et il est bien connus que les développeurs Python et Ruby préfèrent le langage acquis.

  • # Mot de passe salé ?

    Posté par  (site web personnel) . Évalué à 1.

    On dirait que les mots de passe Django n'ont pas de sel. Or c'est une protection critique pour un site web où le risque de fuite est important. Ne pas utiliser de sel est une erreur courante, mais pourtant connue depuis de nombreuses années.

    Extract d'une page OWASP: "Credentials MUST be stored after being one-way hashed and salted using acceptable hashing algorithms".

    https://www.owasp.org/index.php/Guide_to_Authentication#Architectural_Goals

    Passer de SHA1 à PBKDF2 me semble moins utile qu'ajouter du sel. (Les deux émaliorations n'étant pas exclusives.)

  • # Mangez-en, c'est bon !

    Posté par  . Évalué à 8.

    Après quelques années passées à bosser principalement avec RoR (qui elles-même suivaient quelques années de PHP cracra), je suis en train de basculer à Django depuis quelques mois, et je dois dire que je suis vraiment fan.

    Essayez ! Le tutorial en 4 parties est vraiment facile à suivre en quelques heures et donne un très bon aperçu du framework.

    Venant de Rails, c'est très facile à appréhender. C'est à la fois très similaire et très différent (culturellement parlant, j'ai un peu du mal à formuler mes idées correctement sur ce point). Je crois que ça reflète finalement assez bien la différence entre les mondes Python et Ruby.

    La qualité de la documentation (ou plus généralement le soucis de ne pas laisser l'utilisateur dans la merde, par exemple au niveau de la politique de mise à jour) et l'application d'Admin sont deux killer-features à mon sens.

    • [^] # Re: Mangez-en, c'est bon !

      Posté par  . Évalué à 10.

      J'ajouterais que mon première impression venant de Rails a été du genre: "il y a pas telle feature super cool, telle syntaxe méga-hype, ils suivent pas telle convention que-tout-le-monde-doit-suivre-sous-peine-d'être-ringard, tel gem magique, …". Puis je me suis rendu compte que ce que je perdais en coolitude, je le regagnais largement en confort et sérénité au quotidien (notamment quand je dois updater 5 vielles applics sur la journée!).

      En résumé très grossièrement, c'est comme ça que j'ai ressenti la différence culturelle dont je parlais dans mon post précédent. Puis le coté "religieux" de la communauté Rails commençait à sortir par tous les trous du vieux sceptique que je suis.

    • [^] # Re: Mangez-en, c'est bon !

      Posté par  . Évalué à 3.

      J'ai le même parcours que toi, et j'ai la même impression, Django > RoR > ZendFramework.
      Je n'avais jamais codé aussi vite des webapps qu'avec Django.

      • [^] # Re: Mangez-en, c'est bon !

        Posté par  . Évalué à 4.

        Et toi qui connais les 3, quel est ton sentiment sur Zend Framework ?

        (HS, mais c'est plus facile de s'y retrouver en tapant la causette avec quelqu'un qui a les mêmes ref. que soi!)

        • [^] # Re: Mangez-en, c'est bon !

          Posté par  . Évalué à 9.

          J'ai eu beaucoup de bugs, très peu de docs avec des exemples concrets, il n'y a que de la théorie dans leurs docs.
          Pas grand monde poste des informations sur le net et peu d'extensions existent, et c'est très verbeux.

          Pour te donner un ordre d'idées, je dois faire pas mal de petites webapps. Les mêmes webapps avec zf ça me prenait 2 semaines en moyenne et pas sûr du résultat, avec django, je suis à 1 à 2 jours, et pas de bugs.

          C'est possible parce que dans django tu as plein d'applications réutilisables: http://djangopackages.com

          Rails c'est mieux architecturé que zf, mais g eu aussi pas mal de bugs, le patch de gems est obligatoire.

          Franchement, le retour sur investissement avec django, vaut la peine de s'y mettre, même si on ne connaît que PHP.

          Par contre, il faut perdre les mauvaises habitudes qu'on a en PHP, où la culture de la librairie est beaucoup moins forte. Là où en PHP tu vas devoir réinventer la roue parce que personne n'a fait une librairie potable, en python/django, c'est rare que telle fonctionnalité n'existe pas sous forme de librairie.

          • [^] # Re: Mangez-en, c'est bon !

            Posté par  (site web personnel) . Évalué à 4.

            Je sais, mon commentaire est un "Y a qu'à, faut qu'on"… mais se qui serait pratique ça serait un site spécialisé par exemple dans le passage de Php à Django.

            Prendre par la main les dev Php, donner des exemples concrets en Php et comment les réaliser en Python / Django.

            • [^] # Re: Mangez-en, c'est bon !

              Posté par  . Évalué à 2.

              Le problème, c'est que si tu fais du PHP pur, tu ne vas pas trouver tes marques rapidement en Django. La logique est différente.
              Et faire du Python comme on fait du PHP, tu peux t'en approcher, mais ça perd bcp de son intéret, il vaut vraiment mieux partir d'un framework Python comme Django, Pyramid, Flask, Bottle…
              Python ne fonctionne pas comme PHP, il est beaucoup plus proche de Ruby ou Java dans le fonctionnement (pas la lourdeur).

              Par contre, si tu fais du Zend Framework ou du Rails ou tout autre framework, fais le tutorial en 4 parties de Django, et tu vas comprendre rapidement l'intérêt.

        • [^] # Re: Mangez-en, c'est bon !

          Posté par  . Évalué à 3.

          Je n'avais pas vu que tu es belge, je serais à l'afpyro ce vendredi si tu veux en discuter de vive voix: http://linuxfr.org/news/afpyro-a-liege-le-vendredi-30-mars

      • [^] # Re: Mangez-en, c'est bon !

        Posté par  (site web personnel) . Évalué à 1.

        J'ai beaucoup travaillé avec Django, et ce depuis la version 0.91. C'est un framework formidable. Le seul défaut que je lui trouve se situe au niveau des formulaires. Cette version 1.4 arrive bien longtemps après la version 1.3, et elle n'apporte pas de grosses nouveautés. La seule chose intéressante que je trouve dans le changelog est le prefetch_related, qui remplace le select_related, qui peut améliorer beaucoup de choses au niveau des performances SQL. LA grosse nouveauté étant un meilleur support des fuseaux horaires \o/ Bref, j'attendais beaucoup au niveau des formulaires, et y'a pas ce que je veux… Je m'explique :

        • Je veux faire une validation au niveau d'un champ de formulaire en fonction de l'utilisateur identifié. Pour cela, il me faut accéder au request.user dans l'objet Form. Et là, pas possible directement ! Je dois redéfinir la méthode init avec un nouveau paramètre request, ce qui rend l'instanciation incompatible avec les vues génériques. Le moyen le plus pratique que j'ai trouvé est de déclarer la classe dans une méthode qui prend en paramètre ce paramètre request, ce qui me donne très peu de code à réécrire au niveau de la vue. Mais niveau performance, ce n'est pas bon du tout, sans parler de l'élégance ! Je me retrouve avec quasiment chacun de mes formulaires encapsulés dans une méthode.
        • Les Formsets sont lourds à implémenter quand on veut faire quelque chose d'un peu plus poussé qu'une simple liste de formulaires. Par exemple, pour des formulaires imbriqués. J'ai développé un petit outil pour simplifier la chose.
        • Les Formsets (encore eux) ne sont pas fiables (en tous cas pour la version 1.3). Un simple exemple dans une page d'admin de django, en activant l'édition inline dans les listes, en modifiant le code html du management_form à la main avant soumission (en augmentant le champ INITIAL_FORMS), on se retrouve avec une jolie erreur 500. Je vais tester avec django 1.4, mais je me pose de plus en plus de questions sur la fiabilité de la mise en production des formulaires tels qu'ils sont implémentés dans django.
        • Les validations dans les formulaires peuvent être différentes de celles dans les modèles, et c'est trop souvent le cas. C'est un désastre pour la cohérence de la base de données quand on utilise le shell python pour manipuler les objets, même si ça peut apporter un intérêt dans certains cas.
        • Je n'aimais pas rails à ses débuts, c'est pour ça que j'avais choisi django à cette époque. Mais devant la loooooongue attente pour résoudre ces problèmes, et voyant que django 1.4 n'allait rien arranger, je me suis penché sur la version 3.1 de rails, qui supporte les nested forms (depuis la version 3), qui me permet d'assigner le propriétaire lors de la création d'un objet dans un formulaire automatiquement, … Et il n'y a pas cette notion de formulaire, entre le contrôleur et la vue, chose qui me pose problème dans django, justement !!! Alors, non, je dis Django n'est pas un framework MTV, mais un framework MTFV (Modèle Template Formulaire View, ou VTFM, vas te fa… mett.. si tu veux qqch de plus avancé…), tant cette notion de formulaire est importante et contraignante dans django !

        Avez-vous déjà eu ce genre de problèmes ? Avez-vous des réponses à m'apporter ? Est-ce que django n'est pas adapté à ce que je voudrais en faire ?

        • [^] # Re: Mangez-en, c'est bon !

          Posté par  . Évalué à 3.

          Je ne sais pas, je n'ai pas de problèmes avec les formulaires Django, je ne suis pas certain de comprendre tes problématiques.

          Tu peux venir en discuter sur le chan IRC #django-fr

          Il y a aussi des systèmes de formulaires alternatifs comme: http://django-floppyforms.readthedocs.org/en/latest/index.html

          • [^] # Re: Mangez-en, c'est bon !

            Posté par  (site web personnel) . Évalué à 1.

            Ce système de formulaires doit être très bien pour l'aspect cosmétique, ou l'écriture du code HTML. Je ne vois rien (je ne connais pas bien ce projet, je me trompe peut-être) pour résoudre la problématique des formsets, et encore moins l'idée des formulaires imbriqués.

        • [^] # Re: Mangez-en, c'est bon !

          Posté par  (site web personnel) . Évalué à 3.

          Je veux faire une validation au niveau d'un champ de formulaire en fonction de l'utilisateur identifié […]

          Je pense que ton soucis de passer le request.user en argument à ton contrôleur de formulaire avec les vues génériques doit pouvoir être simplifié avec l'arrivée des Class Based Views, qui te permettent d'étendre facilement les vues génériques une fois pour toute dans ton projet ou une librairie et ensuite les utiliser directement sans avoir à redéfinir des méthodes et hack un peu partout.

          Et c'est plus pour l'aspect cosmétique mais l'utilisation des formulaires devient encore plus sympa avec l'utilisation de django-crispy-forms, ça forme directement un joli layout de ton formulaire, layout que tu peux customiser facilement, voir réutiliser dans tes autres formulaires, et qui permet de plus avoir à gérer champ par champ toute les variations d'aspect que tu peux avoir parfois.

          Les validations dans les formulaires peuvent être différentes de celles dans les modèles, et c'est trop souvent le cas […]

          Il n'y a pas de réelle validation dans les formulaires sinon ceux des champs de ton modèle, mais c'est plutôt de la validation de type, pas de logique de ton formulaire. Si tu a de la validation à faire lors de l'enregistrement d'une entrée au niveau de l'API, le plus souple est de le faire dans un manager où tu peux lever des exceptions cohérentes si besoin. Puis si besoin tu peux même le lier après au ModelAdmin de ton modèle pour que ça fonctionne aussi dans l'administration de Django.

          Mais devant la loooooongue attente pour résoudre ces problèmes, et voyant que Django 1.4 n'allait rien arranger […]

          Les releases de Django essayent en général de temporiser entre les gros changements ou ajouts, la 1.3 c'était l'arrivée Class Based Views, la 1.4 laisse un peu le temps aux développeurs pour les implémenter vu que les function views seront deprecated à partir de la 1.5.

          • [^] # Re: Mangez-en, c'est bon !

            Posté par  (site web personnel) . Évalué à 1.

            Je pense que ton soucis de passer le request.user en argument à ton contrôleur de formulaire avec les vues génériques doit pouvoir être simplifié avec l'arrivée des Class Based Views […]

            Oui, mais ça ne résout absolument pas le problème des validations, elles auraient besoin du request quand même ! Et les avoir dans le init empêche l'écriture correcte des validations, sauf si on met l'objet request dans l'instance de l'objet. Je trouve pas ça top.

            Et c'est plus pour l'aspect cosmétique

            Rien à dire au niveau de l'écriture des templates, tout est faisable, sauf dans des cas particuliers où l'écriture d'un tag ou d'un filtre peut s'avérer… fastidieuse (ex : j'ai prévu une méthode dans mon objet pour faire de l'affichage. Cette méthode prend un paramètre : l'utilisateur actuellement identifié. Je ne peux pas l'appeler directement, je dois exécuter cette méthode pour le passer dans le contexte au niveau de la vue, ce qui n'est pas faisable dans le cas de l'affichage d'une liste d'objets, donc je dois écrire un tag…)

            Il n'y a pas de réelle validation dans les formulaires sinon ceux des champs de ton modèle

            Pas d'accord : il y a toute une page sur la validation des champs de formulaire… D'ailleurs, tous les champs de formulaire ne sont pas nécessairement associés à un champ de modèle. Et justement, cette validation fait double emploi, à mon sens, avec les validateurs qui, eux, agissent au niveau du modèle.

            Les releases de Django essayent en général de temporiser entre les gros changements ou ajouts, la 1.3 c'était l'arrivée Class Based Views, la 1.4 laisse un peu le temps aux développeurs pour les implémenter vu que les function views seront deprecated à partir de la 1.5.

            Et alors ? Le temps n'a rien à voir avec le numéro de version. Je trouve leur timeline mal fichue, et des fonctionnalités (je veux dire des outils qui apportent un réel plus au développeur, comme des travaux sur les formulaires) se font, à mon sens, attendre. Je parle par exemple d'outils pour une meilleure gestion des fichiers statiques (pour faire du less, ou pour compresser le JS, ou encore créer automatiquement des sprites), ou bien un outil intégré pour faire les migrations, … Alors oui, on va me dire qu'il existe des outils externes (j'en utilise plein), mais j'ose la comparaison avec rails (que je ne maîtrise absolument pas pour l'instant, je suis encore en phase de découverte du produit) et quel bonheur de se retrouver avec plein d'outils qui simplifient la vie dès le début du projet !
            Je crois que je pourrais encore bcp critiquer Django, et pourtant je l'utilise tous les jours pour un projet relativement vaste. Ça me fait mal de dénigrer ce projet, car Django m'a sauvé la vie plus d'une fois et m'a fait apprécier le développement web. La version 1.4 m'a déçu parce qu'elle a été longue à arriver pour aucune nouveauté apparente. Dire que ZE big news est la gestion des dates après 1 an de développement, je reste un peu sur ma faim…

            • [^] # Re: Mangez-en, c'est bon !

              Posté par  (site web personnel) . Évalué à 1.

              Ah oui je me suis mal relu, je me suis trompé sur Il n'y a pas de réelle validation dans les formulaires sinon ceux des champs de ton modèle je voulais parler de la validation dans les modèles.

              Mais quand il t'arrive d'avoir besoin de forcer une validation au niveau du modèle je produis un dérivé d'un champ de base (si je ne l'ai pas déjà dans une librairie tierce) que j'utilise directement dans le modèle, tu peux y redéfinir la validation du champ, son Widget par défaut, etc.. une fois implémenté au niveau du modèle en général tu n'a pas besoin de le remonter dans les formulaires de tes vues. Ce n'est pas ce que tu veux ?

        • [^] # Re: Mangez-en, c'est bon !

          Posté par  (site web personnel) . Évalué à 2.

          Le mercredi 28 mars 2012 à 12:25 +0200, Damien Szczyt a écrit :
          > Avez-vous déjà eu ce genre de problèmes ? Avez-vous des réponses à m'apporter ?

          Pourquoi ne fais tu pas la manip dans ta vue du genre :

          class PhotoCreateView(CreateView):
          model = Photo
          form_class = PhotoCreateForm

          @method_decorator(login_required)
def dispatch(self, *args, **kwargs):
    return super(PhotoCreateView, self).dispatch(*args, **kwargs)

def form_valid(self, form):
    obj = form.save(commit=False)
    obj.author = self.request.user
    obj.save()
    return super(PhotoCreateView, self).form_valid(form)

          • [^] # Re: Mangez-en, c'est bon !

            Posté par  (site web personnel) . Évalué à 1.

            Parce qu'en faisant ça, tu lances 2 fois la commande save() sur ton objet : une fois avec obj.save() et une fois avec super(…).form_valid(form). Ce n'est pas optimal, et donc pas acceptable pour un usage intensif.

        • [^] # Re: Mangez-en, c'est bon !

          Posté par  . Évalué à 2.

          Bon ça me rassure un peu de ne pas être le seul.
          J'ai eu aussi certains de tes problèmes notamment j'ai galéré avec l'utilisation des formsets.

  • # Explicit is better than implicit

    Posté par  (site web personnel) . Évalué à 7.

    Je ne sais pas pour les dernières versions, mais l'expérience que j'ai eu avec Python et Django est exactement l'inverse de ce principe: tout est dynamique, plein de comportements par défauts et de fonctionnalités cachées heureusement bien détaillés dans la documentation, mais pas du tout explicite.

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: Explicit is better than implicit

      Posté par  . Évalué à 6.

      Ca dépends ou on mets la limite… De mon expérience, il y a évidemment beaucoup plus de magie que dans un script PHP brut (sans framework), mais beaucoup moins que dans un framework comme Ruby on Rails.

      Après, chacun doit voir ou il souhaite placer le curseur, entre "je code vite" et "je maitrise le moindre rouage". Perso Django met ce curseur au bon endroit pour moi, mais je comprends qu'un autre ne le sente pas comme ça.

    • [^] # Re: Explicit is better than implicit

      Posté par  (site web personnel) . Évalué à 3.

      C'était probablement au temps de Django 0.9.x, car de la version 1.0 à la 1.1 il y a eu un énorme boulot pour nettoyer toute la magie, il n'y en a plus vraiment maintenant parce que le peu qu'il doit rester est largement documenté dans ses comportements.

  • # Convore

    Posté par  (site web personnel) . Évalué à 0.

    Convore, c'est ce truc qui ferme dimanche là ? Au profit de https://grove.io/ d'ailleurs.

  • # Python 3

    Posté par  . Évalué à 4.

    Puisque personne ne le dit : je suis très étonné que django ne supporte pas Python 3 plus de trois ans après sa sortie. J'attendais plus ou moins sa sortie pour apprendre python/django. Pour l'instant, je suis très satisfait avec ruby on rails. Personne d'autre que moi n'attend le support de python 3 ? C'est si compliqué que ça de passer d'une application python 2 vers python 3 ?

    • [^] # Re: Python 3

      Posté par  . Évalué à -3.

      Bof, je ne trouve pas que ce soit si urgent que ça. Je n'ai pas l'impression qu'il soit particulièrement en retard par rapport aux autres applications python.

    • [^] # Re: Python 3

      Posté par  . Évalué à 4.

      Je crois que le problème d'être compatible à la fois avec Python 2.5 et 3.x est plus problématique qu'être compatible uniquement 3.x (et comme il doit y avoir encore pas mal de python 2.5)

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Python 3

        Posté par  (site web personnel) . Évalué à 1.

        Même si ta remarque est pertinente, je trouve que que la communauté des devs pythons devraient faire un peu de lobbying. J'entends par là, promouvoir grâce à un effort conjoint des devs des gros framework python comme django le passage en 3.x.

        Pour ceux qui comme moi sont dans le dev en milieu pro, nous ne savons que trop bien ce que représente la dette technique engendrée par le maintien d'une ancienne version de langage.

        Alexandre COLLIGNON

Suivre le flux des commentaires

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