Journal Django 1.5 beta

Posté par (page perso) . Licence CC by-sa
Tags :
23
28
nov.
2012

Dans l'un des journaux précédents, on nous compte une soirée de déboire avec Wordpress avant de faire une avalanche de louange pour django.
http://linuxfr.org/users/booga/journaux/code-facetieux-dans-piwik-1-9-2

Une information vient pourtant de paraitre, Django passe de manière expérimental en version 1.5. Nullement intéressant n'est-ce pas ?

Pour autant, cette pré-version apporte une surprise de taille. Python 3 est supporté de manière expérimentale. Bon nombre d'utilisateur de python 3 rechignait à passer sous django pour faire du web et bon nombre d'utilisateur de de python 3 rechignait à essayer Django. Voilà un processus bien entamé.

On me signale aussi dans le coin de l'oreillette que le modèle utilisateur est maintenant pleinement configurable.

https://docs.djangoproject.com/en/dev/releases/1.5-beta-1/

  • # Formulation

    Posté par . Évalué à  5 .

    J'crois tu voulais dire quelque chose comme :

    « Bon nombre d'utilisateur de Django rechignait à passer sous Python 3, et bon nombre d'utilisateur de Python 3 rechignait à essayer Django. »

    J'suis assez d'accord, mais j'ai envie de dire : c'est surtout que Django (et bon nombre d'autres librairies) n'ont pas été assez rapide à passer à Python 3 (niveau complexité ça n'a pas l'air pourtant si compliqué quand on voit que même un script peut le faire).

    "Never trust a statistic you haven't faked yourself."

    • [^] # Re: Formulation

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

      Le problème est un peu plus complexe que ça, parce que django a son propre écosystème. Du coup, ils doivent bien gérer la transition si ils veulent pas scinder leur communauté et passer à leur tour 5 ans à tenter de recoller les deux bouts.

      Du coup, ils ont attendu que python 3 soit assez mature, et surtout d'avoir pleins de retour d'expérience sur les transitions, car ils ne vont pas seulement faire la transition, ils vont guider la transitions d'un bon paquet de libs.

      • [^] # Re: Formulation

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

        Une autre raison, expliqué dans une discussion sur Hacker news est que l'équipe de Django voulait maintenir la rétro-compatibilité avec les anciennes version de Python (2.3). Ils ont pas mal d'utilisateurs qui sont sur des vieilles distrib (genre RHEL) et qui ne peuvent pas juste faire une mise à jour de la distrib parce qu'ils ne sont pas admin.

        J'imagine que c'est chaud d'avoir un code qui tourne à la fois sous 2.3 et 3.3. C'est plus simple d'être compatible 2.6 et 3.3 parce que la 2.6 intègre certaines fonctionnalités de python 3. Donc ils ont attendu que leurs utilisateurs migrent vers une version plus récente de Python.

    • [^] # Re: Formulation

      Posté par . Évalué à  4 .

      Le principal changement de python3 réside dans la gestion des chaînes de caractère ce qui explique la difficulté du passage a la nouvelle version de python.

      • [^] # Re: Formulation

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

        Maintenant, faut mettre des parenthèses aux print. ;)

        La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick

      • [^] # Re: Formulation

        Posté par . Évalué à  2 .

        Python 3.3 assure en partie la rétrocompatibilité en acceptant la syntaxe u"mystring".

    • [^] # Re: Formulation

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

      Il me semble aussi que tout ce qui est interface avec http et les serveurs web a été quelques temps en discussion dans la communauté des développeurs des différents frameworks, afin d'arriver à une interface claire (avec entre autres le problème bytes vs str unicode).

      PEP 3333—Python Web Server Gateway Interface v1.0.1

      • [^] # Re: Formulation

        Posté par . Évalué à  3 .

        Tu parle de WSGI qui n'a rien de spécifique à python 3.

        Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

        • [^] # Re: Formulation

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

          Un peu quand même:

          This is an updated version of PEP 333, modified slightly to improve usability under Python 3, and to incorporate several long-standing de-facto amendments to the WSGI protocol. (Its code samples have also been ported to Python 3.)

          • [^] # Re: Formulation

            Posté par . Évalué à  3 .

            Mince j'ai confondu la PEP 333 avec la PEP 3333.

            Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

    • [^] # Re: Formulation

      Posté par . Évalué à  6 .

      on nous compte une soirée de déboire

      J'espère que ce n'est pas cher :)))

      • [^] # Re: Formulation

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

        Pardon au famille, tout ça, pour l'orthographe.

        La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick

        • [^] # Re: Formulation

          Posté par . Évalué à  2 .

          T'inquiètes, tu nous payeras un demi-coup à boire lors des prochaines unhappy hours

  • # Modèle User

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

    On peut en effet modifier le modèle User. C'est plutôt pas mal, car le modèle d'origine est tout de même assez basique. Maintenant, on peut rajouter tous les attributs dont on a besoin. De façon générale, il y avaient un certain nombre de choses qui étaient spécifiques aux modules d'authentification et d'admin.
    Maintenant, ce n'est plus le cas, et ils deviennent des modules comme les autres.

    Django commence à devenir vraiment bon avec cette version 1.5 !

    • [^] # Re: Modèle User

      Posté par (page perso) . Évalué à  -10 .

      Je suis un dev Ruby on Rails et ce genre de trucs me fait légèrement rigoler :D…

      • [^] # Re: Modèle User

        Posté par . Évalué à  9 .

        Moi ce qui me fait rigoler c'est un mec qui dit "Je suis un dev Ruby on Rails".

        Pour repprendre ce que disais CrEV y'a pas longtemps "ne soyez pas un développeur PHP, Python, Ruby, JavaScript… mais soyez un développeur Web". J'irais même plus loin en disant "Soyez un développeur".

        Il est très intéressant d'avoir les retours constructifs des gens qui utilisent plusieurs choses ca permet de s'ouvrir l'esprit, de comparer, de comprendre les points forts et faibles, les angles d'attaques possibles etc. Par contre le boulet qui arrive avec ses gros sabots "RoR c'est trop génial c'est la réponse à tout" je saisi pas trop l'intêret…

        • [^] # Re: Modèle User

          Posté par (page perso) . Évalué à  -1 .

          Moi ça me fait rigoler un mec qui dit "je suis développeur".

          Pour reprendre ce que disais Maître Xhang y a pas longtemps "ne soyez pas un développeur", mais "soyez un Homme". Ne l'oubliez pas, nous avons tous un coeur. Oubliez un peu vos ordinateurs et regardez un peu plus le monde qui vous entoure, voyagez, vous serez surpris.

      • [^] # Re: Modèle User

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

        Et au lieu de te contenter de dire ça, pourquoi ne pas expliquer en quoi RoR est-il supérieur à Django ?

        • [^] # Re: Modèle User

          Posté par (page perso) . Évalué à  -1 .

          Bien sûr que non je ne pense pas qu'un framework soit supérieur à un autre, ou que Rails est mieux que Django.
          Je constate juste que les philosophies sont différentes. L'équipe de Rails-core a volontairement choisi de ne pas insérer de logique trop axée métier dans le framework. Dans Rails 1 on trouvait des objets permettant de gérer des listes ou des arbres dans une base de données relationnelle, ces objets ont été extraits.
          De même on ne trouve pas de framework d'authentification, d'authorisation ou de générateur d'interface d'admin directement au sein de Rails.
          Et finalement moi j'apprécie bien ce découplage.

          • [^] # Re: Modèle User

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

            À la base, Django était un framework fait maison pour le site web d'un journal, ce qui explique certains couplages.
            Mais, au cours du temps, ces modules de base (authentification, admin, …) sont passés dans le dossier contrib, qui regroupe les modules non essentiels, mais utiles quand même dans 99% des cas.

            C'est aussi ça l'intérêt de Django, quasiment à chaque fois que j'ai besoin de faire quelque chose, c'est soit fourni de base dans le cœur du framework, soit dans les contrib.

  • # Scaffolding

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

    Juste une question comme ça…

    Y a-t-il désormais du scaffolding dans Django ?

    Pour info, avec CakePHP (ou Ruby on Rails), il est très facile de générer à partir de la base de donnée (en respectant quelques conventions) directement le code du modèle, de la vue et du conroleur (et faire ensuite les modifications comme on veut)…

    C'est assez sympa le concept de "convention over configuration"… je ne sais pas si Django utilise cette idée…
    http://book.cakephp.org/1.3/en/The-Manual/Basic-Principles-of-CakePHP/CakePHP-Conventions.html
    http://fr.wikipedia.org/wiki/Convention_plut%C3%B4t_que_configuration

    • [^] # Re: Scaffolding

      Posté par (page perso) . Évalué à  2 . Dernière modification : le 29/11/12 à 22:09

      Je ne suis pas sûr de bien avoir saisi ce que tu veux dire, mais dans le doute, je vais tout de même répondre.

      Avec Django, tu n'es pas censé voir du SQL. Tu écris tes classes Python (*) qui servent de modèle, et tu peux utiliser des « views » génériques (qui correspondraient plutôt au contrôleur dans MVC). Il ne te reste plus qu'à écrire un template avec un peu de HTML (la vue du MVC).

      Quand tu pars d'un projet existant, tu n'as aucune raison de partir de la base de données… car elle n'existe pas.

      En tout cas, Django utilise beaucoup les conventions, si ça peut te rassurer.

      (*) exemple :
      class Book(models.Model):
      title = models.CharField("titre", max_length=255, primary_key=True)
      author = models.CharField("auteur", max_length=255)

      Ça génèrera une table SQL avec deux colonnes de VARCHAR, mais tu pourras manipuler uniquement des objets Python.

      • [^] # Re: Scaffolding

        Posté par . Évalué à  5 .

        Je pense que tu voulais plutôt écrire ça :

        class Book(models.Model):
            title = models.CharField("titre", max_length=255, primary_key=True)
            author = models.CharField("auteur", max_length=255)
        
        

        :)

    • [^] # Re: Scaffolding

      Posté par . Évalué à  3 .

      Y a-t-il désormais du scaffolding dans Django ?

      Il faudrait que tu précises vraiment ce que tu recherches.

      Tu as un module pour générer les les modèles à partir d'une DB existante: inspectdb. Jamais utilisé donc je ne sais pas la pertinence de l'utiliser.

      Pour la vue et le contrôleur à ma connaissance il n'existe rien de built-in. D'un autre côté il me semble que dans 99% des cas tu vas de toute façon très rapidement jeter tout le code généré. Si tu as un exemple précis de cas où ça apporte vraiment quelque chose ça m’intéresse. Django à fait le choix de permettre de de monter automatiquement, ou presque, vue et contrôleur pour la partie admin par ce que ça fait un sens et que c'est un réel gain de temps durable. Côté public je suis moins convaincu de l’intérêt. Après il existe certainement des applications pour faire ça. Par exemple pour ceux qui préfèrent partir de templates fonctionnels plutôt que tu fichiers vides il existe des apps.

      C'est assez sympa le concept de "convention over configuration"… je ne sais pas si Django utilise cette idée…

      On peut discuter longtemps sur les détails mais de manière générale oui. Tu n'as pas à spécifier ou écrire des choses qui auraient pu être inférer ou dont il y a une valeur raisonnable par défaut.

      • [^] # Re: Scaffolding

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

        Désolé de ne répondre qu'avec pas mal de retard.

        En fait l'idée du scaffolding c'est de créer automatiquement tout le code nécessaire pour les opérations CRUD (Create Read Update Delete)
        http://fr.wikipedia.org/wiki/CRUD

        Il est vrai que les vues ainsi gérées peuvent avoir besoin d'être pas mal modifiées… mais cela évite d'avoir à partir d'une feuille blanche.

        http://book.cakephp.org/2.0/fr/controllers/scaffolding.html

        En fait le problème c'est que j'aime bien CakePHP… mais pas le PHP (je préfère Python)

        Donc je cherche un framework en Python qui lui ressemble.

        • [^] # Re: Scaffolding

          Posté par . Évalué à  2 .

          Honnêtement avec django-admin + les vues génériques t'en es pas loin. La vraie différence je pense c'est que django te force à définir l'urldispatcher, mais après tout si y'a bien un truc que tu veux controller et qui ne peut être inférer c'est ca. Après sauf si il existe une app que je ne connais pas il faut écrire ces quelques lignes de code. C'est peut être un poil plus difficile au début vu qu'il faut découvrir ce que tu peux faire, par contre l'avantage c'est que tu pars direct sur de bonnes bases que tu vas faire évoluer au fur et à mesure que tu itères.

Suivre le flux des commentaires

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