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.
# Formulation
Posté par Oles . É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 Georges Dubus (site web personnel) . É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 Jux (site web personnel) . É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 Albert_ . É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 Thom (site web personnel) . É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 coid . Évalué à 2.
Python 3.3 assure en partie la rétrocompatibilité en acceptant la syntaxe u"mystring".
[^] # Re: Formulation
Posté par lolop (site web personnel) . É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
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Formulation
Posté par barmic . Évalué à 3.
Tu parle de WSGI qui n'a rien de spécifique à python 3.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Formulation
Posté par lolop (site web personnel) . Évalué à 5.
Un peu quand même:
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Formulation
Posté par barmic . Évalué à 3.
Mince j'ai confondu la PEP 333 avec la PEP 3333.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Formulation
Posté par lolop (site web personnel) . Évalué à 3.
Quelques liens:
La réponse de ncoghlan sur la page Why do people hesitate using Python 3? précise un peu les problèmes et l'historique avec les déclinaisons de Python3.
Un article de Armin Ronacher sur WSGI et Python3 (en 2010), plus précis sur les problèmes d'encodage pour toutes les infos qui se baladent de différentes façon via HTTP.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Formulation
Posté par oinkoink_daotter . Évalué à 6.
J'espère que ce n'est pas cher :)))
[^] # Re: Formulation
Posté par Thom (site web personnel) . É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 El Titi . Évalué à 2.
T'inquiètes, tu nous payeras un demi-coup à boire lors des prochaines unhappy hours
# Modèle User
Posté par flan (site web personnel) . É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 Nicolas Blanco (site web personnel) . É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 ckyl . É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 Nicolas Blanco (site web personnel) . É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 flan (site web personnel) . É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 Nicolas Blanco (site web personnel) . É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 flan (site web personnel) . É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 scls19fr (site web personnel) . É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 flan (site web personnel) . Évalué à 2. Dernière modification le 29 novembre 2012 à 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 Anonyme . Évalué à 5.
Je pense que tu voulais plutôt écrire ça :
:)
[^] # Re: Scaffolding
Posté par ckyl . Évalué à 3.
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.
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 scls19fr (site web personnel) . É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 ckyl . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.