Mais c'est quoi Beer Over IP ?

BeerOverIP est un "protocole" permettant à un internaute d'envoyer une bière virtuelle à quelqu'un d'autre. Pour le remercier, par exemple. Ou étancher sa soif. Pour utiliser ce protocole, c'est facile, il suffit d'envoyer un lien vers beeroverip.org au destinataire, et le tour est joué !

Nouveautés

• Grâce à Victor Stinner (plutôt connu sous le pseudo de *haypo* dans la communauté Python), j'ai rajouté la Leffe Brune et le Picon à la liste des breuvages disponibles.
• La discussion qui a amené aux ajouts ci-dessus m'a rappelé qu'il fallait que je signale que le site était propulsé par Django. Logo rajouté.
• En quelques minutes, j'ai intégré un *flot* RSS, afin que tout un chacun soit informé dès qu'une nouvelle bière est disponible pour le transport via IP. Fais chauffer ton aggrégateur.
• Et pour finir (on garde le meilleur pour la fin), j'ai rajouté la Kro à la liste des bières disponibles. Parce qu'il n'y a pas de raison pour qu'on n'envoie que des bonnes bières via ce protocole. Si tu n'aimes pas quelqu'un, tu peux lui envoyer de la pisse d'âne.

Kronebourg, by gzap, Creative Commons licensed, CC-BY-NC-SA.

BUUUURRRRRP !!!

Contribuer

Si parmi les bières disponibles tu ne trouves pas ton bonheur, tu peux élargir notre catalogue soit :

• en adressant un rapport de bug sur la page Launchpad prévue à cet effet. Pour bien faire, si tu as une photo d'une bière manquante, et que tu peux la publier sous une licence libre, tu peux l'ajouter en pièce jointe à ce rapport de bug.
• tu peux aussi me contacter en m'envoyant le nom de la bière, sa photo et une description, ainsi que la licence choisie pour cette image.

J'ai ajouté une template Paste à collective.buildbot:

buildbot@cecilia:~$ paster create --list-template
Available templates:
  basic_package:  A basic setuptools-enabled package
  buildbot:       A template for collective.buildbot
  ...

C'est assez pratique pour monter un buildbot rapidement et pas se prendre la tête en passant des heures à lire la doc.

C'est relativement simple. On utilise la template qui pose quelques questions:

buildbot@cecilia:~$ paster create -t buildbot gawel.org
Selected and implied templates:
  collective.buildbot#buildbot  A template for collective.buildbot

Variables:
  egg:      gawel.org
  package:  gawelorg
  project:  gawel.org
Enter port (the port to use for internal communication) ['9050']: 6050
Enter wport (the port to use for web interface) ['9080']: 6080
Enter vcs (the vcs type. hg, bzr and git are supported.) ['svn']:
Enter vcs_url (the url to checkout from) ['']: https://svn.gawel.org/gp.fileupload/trunk
Creating template buildbot
Creating directory ./gawel.org
blabla...

Et voilà... On lance 2/3 commandes histoire d'avoir quand même un truc à faire. Sinon c'est un coup à devenir feignant:

buildbot@cecilia:~$ cd gawel.org/
buildbot@cecilia:~/gawel.org$ python bootstrap.py
Downloading http://pypi.python.org/packages/2.4/s/setuptools/setuptools-0.6c9-py2.4.egg
blabla...

buildbot@cecilia:~/gawel.org$ ./bin/buildout -U
Creating directory '/home/buildbot/gawel.org/eggs'.
blabla...
Generated script '/home/buildbot/gawel.org/bin/master'.
blabla...
Generated script '/home/buildbot/gawel.org/bin/cecilia'.

On a maintenant deux script qui correspondent au master et au slave. Si vous ignorez ce qu'est un master et un slave, reporté vous à la documentation buildbot.

Y a plus qu'a les lancer:

buildbot@cecilia:~/gawel.org$ ./bin/master start
blabla...

buildbot@cecilia:~/gawel.org$ ./bin/cecilia start
blabla...

Le tout doit pas prendre plus de deux minutes. Et ça marche. Comme quoi des fois un titre à une signification.

Bien sur, on peut affiner la configuration, utiliser Mercurial ou git, etc. Mais il faut lire la doc.

Lors de sa présentation durant DjangoCon, Cal Henderson, co-créateur de Ruby on Railsarchitecte de Flickr et codeur PHP a dressé une liste éloquente des points à cause desquels il détestait Django (certains points sont valides, d'autres légèrement plus discutables, mais ce n'est pas le sujet).

L'un de ces points était :

Django n'a pas de mascotte

Certes. Rails non plus, m'enfin.

Saluons quand même cette très audacieuse tentative par Bryan Veloso pour donner à Django une mascotte :

Django, le framework web pour les poneys à pouvoirs magiques

(image sous contrat Creative Commons - BY-NC-ND)

Mise à jour : Le logo possède une version verte

Pour ma part, concernant une application développée dans le cadre professionnel, j'ai eu l'occasion de migrer d'un 0.96 à un 1.0. En suivant la documentation qui est d'une absolue perfection, on obtient en quelques minutes une version améliorée d'un modèle simple, pour lequel les tests passent et le fonctionnement général du site est identique. S'il fallait noter un framework sur la qualité de sa documentation, Django obtiendrait sans doute un 10/10.

La partie qui a le plus changé est sans doute le mécanisme de l'API de la base de données, ainsi que la branche "newforms-admin" qui refond totalement la manière de générer l'interface de gestion automatique. La création d'un fichier "admin.py" est d'ailleurs extrêmement facilité par ce snippet qui crée le fichier en scannant le fichier "models.py".

Pour ma part, je regrette quand même la disparition des validateurs, qui permettaient d'obtenir un début de contrôle de données très simplement. Au prix de quelques contorsions, c'est encore possible, mais je préférais définir simplement en deux lignes un validateur personnalisé (genre "un nombre entier qui doit se trouver entre 0 et 100 pour un pourcentage"). Less code is more.

En revanche, la partie "test" est absolument bluffante. Non seulement on peut facilement tester les modèles et leurs méthodes, c'est à dire le fonctionnement "sous le capot" de ton application, mais on peut également tester les vues, et mêmes les vues nécessitant une authentification, pour s'assurer que les pages renvoyées sont correctes. Habituellement, cette partie donnait lieu à des tests manuels (genre, pour une boutique, je me connecte, je crée un panier ou encore je remplis un formulaire d'inscription avec des données bidon, ou invalides, ou correctes...). Là, tout peut être résumé à des tests unitaires complets, lancés aussi régulièrement que possibles.

Franchement, cela ouvre des milliers de possibilités, dont celle de coder un site web sans jamais lancer le moindre navigateur. Si, si, on peut.

La migration de JHLP en Django 1.0 me chatouille ; il faudra que je réfléchisse à la question... Mais à mon avis, si je devais commencer une appli en Django ou migrer une application simple en 1.0, je foncerais sans hésiter.

Pour information, chez mon hébergeur Alwaysdata, Django 1.0 est déjà disponible. Qui parlait de réactivité, déjà ?

Pour bénéficier de la toute-puissance de cette application web que le monde nous envie, il suffit d'aller faire un tour sur la liste des bières disponibles. Évidemment, pour le moment, cette liste est assez courte... Mais je suis totalement persuadé que toi aussi, tu peux aider à l'allongement de cette liste en fournissant via l'interface de bug de Launchpad :

• le nom de la bière,
• une photo ou un lien vers cette photo, sachant que ce média doit être absolument libre (license Creative Commons, par exemple),
• les crédits appropriés,

À toi de jouer, bientôt, ta binouze favorite sera accessible à tous et toutes, via l'Internet.

Le code de cette application est publiée sous une double license... Non, pas la license IV, mais presque. L'application est libre, sous license WTFPL et BEERWARE. La première permet de faire ce que tu veux j'en ai rien à foutre, tandis que la suivante pose une condition : tu peux faire ce que tu veux avec ce code, mais si on a l'occasion de se rencontrer dans la vraie vie, tu peux me payer un verre.

À noter qu'on peut, sous réserves de quelques opérations légèrement geeks installer directement PyRoom dans Ubuntu en utilisant le dépôt PPA officiel.

A ouais... taper

sudo apt-get install pyroom

Trop bien.

Support complet de l'Unicode

Mergée l'été dernier, le nom de cette branche est assez explicite. Terminés les problèmes de charset/encoding lorsqu'on a des données propres, sinon iconv est votre ami.

Commandes personnalisées

La refactorisation des commandes internes de Django permet depuis un an d'ajouter très facilement des commandes personnalisées à votre projet. Vous pouvez par exemple voir ce que ça donne sur le script qui récupère les flux affichés dans la sidebar de ce site.

Échappement des variables dans les templates

Changement de la politique de sécurité en novembre dernier avec les variables échappées par défaut. Selon les cas, ça peut être pénible pour les mises à jour mais c'était à mon avis utile pour permettre aux débutants de ne pas faire trop d'erreurs à ce niveau. Il est toujours possible de contourner cette restriction via le filtre |safe ou le tag autoescape (great power, great responsabilities, tout ça).

Refactorisation des querysets

Fin avril, un énorme boulot est effectué en interne afin de corriger pas mal de bugs récalcitrants, ça permet (entre autres) d'ordonner plus facilement les querysets, de spécifier les champs couverts par un select_related, d'optimiser la façon de filtrer les résultats, de mettre à jour plusieurs instances d'un coup et surtout, le retour de l'héritage au niveau des modèles !

Modifications dans l'upload de fichiers

Début juillet, ça commence à s'accélérer, il est maintenant possible de lire les fichiers uploadés partie par partie. Ça n'a l'air de rien mais selon les types de fichiers sur lesquels vous travaillez ça peut vraiment faire la différence.

Nouvelle administration utilisant les newforms

C'est LA fonctionnalité qui donne à mon avis à Django une longueur d'avance sur les autres frameworks. Ajoutée mi-juillet, cette branche permet de générer une interface d'administration qui tient compte des droits utilisateurs, qui est vraiment flexible et customisable. L'interface qui était réservée aux personnes de confiance (administrateur) peut maintenant être utilisée pour développer un site complet. Le problème c'est qu'à partir de cette date là, avec les vacances et les commits qui s'accélèrent il devient plus prudent d'attendre la 1.0 et cette fonctionnalité n'a pas eu la promotion qu'elle méritait à mon avis. Cela dit il est temps de tester sa puissance maintenant, je joue avec depuis quelques jours et c'est vraiment du bonheur.

Ajout du support géographique

GeoDjango est enfin ajouté dans les contrib, très beau projet avec énormément de fonctionnalités indispensables lorsque vous commencez à vouloir savoir qui habite près de qui, quelle est la distance parcourue, etc.

Refactorisation des stockages de fichiers

Bon celui là c'est un peu mon chouchou car je l'ai testé à plusieurs reprises pour faire des retours à Marty Alchin et ça m'a mené à partager certains storages utiles pour Django. Il permet par exemple de stocker ses fichiers en local pour du développement et sur S3 pour de la production ou n'importe quelle combinaison possible et imaginable.

Nouveau système de commentaires

Pour finir, ce qui était attendu depuis... toujours, un GSoC est arrivé à terme ! Les commentaires ont été entièrement réécrits, j'utilise une version alpha de cette implémentation et je ne sais pas si je mettrais à jour, peut-être à l'occasion mais elle a l'avantage de ne pas être standard et pour lutter contre le spam on ne fait pas mieux ;-).

Enfin, il y a eu pas mal de ménage de fait sur d'anciennes parties de code (suppression des oldforms/validators entre autres), ce qui le rend plus facilement maintenable et une nouvelle documentation propulsée par Sphinx (l'outil qui mériterait un petit système de tickets pour être tout à fait parfait). Que du bon. De mon côté, on peut pas dire que j'ai vraiment avancé sur mes tickets, j'ai pas mal discuté de l'intérêt de l'utilisation du tag url dans blocktrans et au final la solution est venue presque par hasard ! J'ai pas eu le temps de m'occuper de tout ce qui était relatif à la séparation des tests mais j'ai mis à jour les traductions (ce qui représentait un sacré boulot, heureusement que j'ai eu de l'aide de la team fr).

Une année riche en nouveautés qui montre le dynamisme du framework, la 1.0 n'était qu'une étape nécessaire permettant de partir d'une base saine. Il y a encore 2/3 choses qui méritent d'être remises à plat pour la 1.1 mais sinon c'est clairement positif. Avec de telles fondations, il devient de plus en plus facile de développer son projet parfait, en tenant les délais ;-). Il ne manque plus que la sortie de Starcraft 2 pour faire le grand chelem...

PS : ça sort dans quelques heures, un peu de patience, je le publie maintenant suite à une petite erreur de ma part. En attendant qu'est-ce qui vous pousse/retient d'utiliser cette version ?

[edit du soir] : bon finalement ça commence par une faille de sécurité qui sera suivie d'une RC1.

[edit du 4 septembre, 1h47] : sortie de la version 1.0. Enfin.

La page officielle de migration est un bon début si vous n'êtes pas à jour.

En attendant que le contenu débarque en masse, on peut tout de même se réjouir et appeler ça une très bonne nouvelle.

Décidément, 2008...

La société pour laquelle je travaille, Interface IP, cherche à recruter un développeur web "agile". Nous travaillons quasi-exclusivement en utilisant le framework web Django, et c'est en priorité ce type de profil que nous recherchons, mais nous n'excluons pas d'étudier les candidatures de développeurs ayant suffisamment de curiosité intellectuelle pour avoir envie de découvrir de nouvelles technologies...

La curiosité c'est bien, mais l'expérience, c'est encore mieux : évidemment, il faut posséder une bonne culture Web et maîtriser au moins un framework web de type MVC (rails, symfony, turbogears, DJANGO) mettra ton CV sur le dessus de la pile. Si en plus tu es familier d'un gestionnaire de révisions (mercurial, bzr, git, svn...) et que tu pratiques le développement dirigé par les tests (TDD), alors c'est le summum.

Notre société est basée à Bayonne, France, et si nous acceptons une dose de télétravail, il est plus facile pour nous d'avoir quelqu'un sur place.

Contacter Sébastien Guibert, en adressant CV + petit mot gentil à recrutement arobase interfaceip point fr

(il n'est pas nécessaire de parler basque pour répondre à l'annonce)

J'ai choisi la license WTFPL pour publier le code. D'abord, parce qu'elle est libre, qu'elle est compatible avec elle-même, et qu'elle correspond tout à fait avec le contenu de cette vaste blague.

En attendant la vidéo...

Me voilà donc partit à la recherche de docs pour pouvoir écrire mes tests comme j'aime les écrire. Pylons utilise nose comme framework de test. Je découvre alors avec joie que nose fournit un plugin pour parcourir les doctests. Chouet !

Le problème, c'est que ce plugin est carrément rudimentaire. En gros, il choppe vos doctest et les initialise ultra basiquement. Comprendre: impossible de passer des options telles que optionflag, setUp ou tearDown. En bref, ça pu. Comment je fais pour initialiser mon framework Pylons pour mes tests moi ? Hein ?

J'ai finalement trouvé une solution en surclassant la classe doctest.DocFileCase afin de faire ce que je veux. Voici le code en question. Il suffit de le placer dans le fichier tests/functional/test_docs.py de votre application Pylons:

# -*- coding: utf-8 -*-
import os
import doctest
import mypylonsapp
from mypylonsapp.tests import *

optionflags = (doctest.ELLIPSIS |
               doctest.NORMALIZE_WHITESPACE |
               doctest.REPORT_ONLY_FIRST_FAILURE)

dirname = os.path.join(os.path.dirname(mypylonsapp.__file__), 'docs')


def build_testcase(filename):
    name = os.path.splitext(filename)[0]
    path = os.path.join(dirname, filename)

    class Dummy(doctest.DocFileCase, TestController):
        def __init__(self, *args, **kwargs):
            # init pylons stuff
            TestController.__init__(self, *args, **kwargs)

            # get tests from file
            parser = doctest.DocTestParser()
            doc = open(self.path).read()
            test = parser.get_doctest(doc, globals(), name, self.path, 0)

            # init doc test case
            doctest.DocFileCase.__init__(self, test, optionflags=optionflags)

        def setUp(self):
            """init pylons stuff and make app available in doctest
            """
            TestController.setUp(self)
            test = self._dt_test
            test.globs['app'] = self.app

        def tearDown(self):
            """cleaning
            """
            TestController.tearDown(self)
            test = self._dt_test
            test.globs.clear()

    # generate a new class for the file
    return ("Test%s" % name.title(),
            type('Test%sClass' % name.title(), (Dummy,), dict(path=path)))

for filename in os.listdir(dirname):
    if filename == '.svn':
        continue
    name, klass = build_testcase(filename)
    exec "%s =  klass" % name

# clean namespace to avoid test duplication
del build_testcase, filename, name, klass

Vous admirerez la ruse qui est de générer une nouvelle classe pour chaque fichier trouvé dans le répertoire contenant les doctests.

On peut ensuite créer un fichier texte dans docs/ et y écrire des tests du genre:

>>> response = app.get(url_for(controller='main', action="index"))
>>> print response
Response: 200
...

Ce qui est tout de même vachement plus convi qu'un test classique.

Toujours est-il que la Django Software Foundation ayant été fondée il y a peu - le jour de mon anniversaire, c'est trop gentil, merci, elle a évidemment besoin de fonds. Comme l'indique la FAQ :

How will my donation be used?
The main focus of the Django Software Foundation is direct support of Django's developers. This means:
- Organizing and funding development sprints so that Django's developers can meet face-to-face — we're far more productive that way.
- Helping key developers attend these sprints and other community events by covering travel expenses to official Django meetups and sprints.

Traduction possible:

Comment mon argent sera-t-il utilisé ?
L'objectif principal de la Django Software Foundation est le soutien direct au développeurs de Django. ce qui signifie :
- l'organisation et le financement de sprints de développement, afin que les développeurs puissent se rencontrer face à face et soient plus productifs de cette manière,
- aider les développeurs-clés à participer à ces sprints et à d'autres événements communautaires en couvrant leurs frais de déplacement à ces rencontres et sprints Django officiels.

Allez, par ici la monnaie !

Mise à jour du 16 juillet 2008, 23:32 :

J'ai donné à Django

Heureusement il y a distutils !!

distutils est un paquet inclus dans les distributions python permettant de créer des paquet python.

Le principe est simple. On englobe un module python dans un paquet contenant un fichier setup.py

Le plus simple est d'utiliser paste pour créer son paquet. Renseignez bien les information demandées. Elles seront visible si vous décidez de distribuer votre paquet par la suite. Donc:

$ easy_install -U PasteScript
$ paster create monscript
$ cd monscript
$ ls
monscript/ monscript.egg-info/ setup.cfg setup.py

Ceci nous créer un répertoire monscript contenant un setup.py et un sous répertoire destiné à recevoir le code python.

Nous devons maintenant créer un point d'entrée pour notre script. Pour cela, nous allons modifier monscript/__init__.py pour qu'il ressemble à ça:

def main():
    print 'Yeah !'

Ensuite, en modifiant le fichier setup.py, nous pouvons associer ce point d'entrée à un véritable script qui sera installé à l'installation du paquet. Modifiez la section entry_points du setup.py pour qu'il ressemble à quelque chose du du genre:

entry_points="""
# -*- Entry points: -*-
[console_scripts]
mon_super_script = monscript:main
""",

Voilà, le tour est joué. Alors, pourquoi tout cela pour un simple script ? C'est simple. Vous pouvez maintenant aisément le distribuer.

Voici les principales commandes qui vous serons utiles:

• créer un tarball:

  $ python setup.py sdist
  

• créer un egg:

  $ python setup.py bdist_egg
  

• rendre le paquet disponible sur pypi:

  $ python setup.py sdist bdist_egg register upload
  

Un utilisateur lambda pourra ensuite l'installer simplement:

• via le tarball:

  $ wget http://exemple.com/monscript-0.1.tar.gz
  $ tar monscript-0.1.tar.gz
  $ cd monscript
  $ python setup.py install
  

• via pypi:

  $ easy_install -U monscript
  

Moralité, distutils rends la vie plus facile.

Maintenant, la conf du Lugradio Live...

Djangonaute ou pas, vient qui veut.

Dans la série "une découverte Python par jour", voici Py2Deb.

Empaqueter des programmes est une tâche indispensable pour diffuser le plus largement possible des applications. Toutes les distributions Linux ont un système de paquets permettant d'installer / désinstaller sans soucis une application, en s'assurant par exemple qu'elle disposera de toutes les bibliothèques de fonction indispensables à son bon fonctionnement. Pour Ubuntu, basée sur Debian, le format des paquets est .deb. Il existe de nombreux tutoriaux, il y a même eu pas mal de cours sur IRC à ce sujet présentant la marche à suivre pour publier un .deb installable sur une machine "debian-based". Y'a même des vidéos.

Et un "je ne sais quoi" me freinait. Je construit de plus en plus d'applications (ou de jeux de scripts) plus ou moins complexes en Python, et la question du paquet se pose toujours à un moment ou un autre. La manière "pythonnienne", c'est d'utiliser les outils de la bibliothèque distutils, et de publier sur le Python Package Index, mais elle nécessite quelques opérations en ligne de commande pour que le commun des mortels puisse installer l'application et s'en servir. Je pense que ce mode de fonctionnement est plus efficace pour une bibliothèque, pour des gens qui savent ce qu'ils font quand ils lancent :

easy_install machin_chose

Un utilisateur lambda voudra télécharger un "machin", et double-cliquer dessus pour que le programme s'installe "tout seul". Et tant que le paquetage à la Debian n'est pas arrivé dans les dépôts (officiels ou officieux), difficile de passer par Synaptic ou Adept.

Py2Deb pallie à la difficulté de concevoir et produire un paquet .deb. Le programme est bien entendu disponible sur le site officiel via un paquetage .deb (à installer avec GDebi, par exemple), et il permet en quelques lignes de python de produire un paquet qui m'a semblé (j'ai pu le tester avec un "hello world" tout con) correct. Ça s'installe, ça se désinstalle, et paf.

Pour ceux que ça intéresse, je leur propose d'aller à la pêche aux infos dans la doc officielle.

Note : le présent article n'a pas été publié sur le Planet Ubuntu-fr pour deux raisons : d'abord parce que je m'interroge depuis quelques temps sur mon implication dans PUF, ensuite, parce qu'il parle de l'installation d'un paquetage ne se trouvant pas (encore) dans les dépôts officiels, et qui plus est, le programme décrit permet même de faire des paquetages.
Ce genre d'article a fait partie de moult polémiques sur la liste de diffusion du PUF ou ailleurs, et ça m'emmerderait assez que cette publication provoque une nouvelle vaguelette (dans le verre d'eau).

Pour ceux qui auraient les jetons, j'ai regardé le code source de Py2Deb ne fois installé : il n'y a guère qu'un script Python... Globalement inoffensif.

J'ai finalement été assez surpris. Déjà, on trouve dans le trunk de django un WSGIHandler. C'est la fête ! Il ne reste plus qu'as l'associer à paste. Bon, je me lance.

La première chose que j'ai faites a été de transformer l'application en egg. Je comprends pas que ce ne soit pas fait de fait dans la template django... Soit, un simple setup.py et mon application peut-être intégrée dans mon buidlout.

Ensuite, première tentative pour utiliser ce précieux handler: créer une usine qui renvois le WSGIHandler tel quel. Échec. Forcément, django attends son fameux module de settings. Soit, avec un peu de chance, en le plaçant dans l'environ utilisé par l'usine, on vas y arriver. Re-échec.

Pourquoi ? Tout bêtement parce que django vas chercher cette valeur dans os.environ. Et là, c'est le drame. Enfin non, c'est à moitié le drame. En effet, en initialisant correctement la variable qui vas bien, on arrive finalement à utiliser ce handler.

Second problème, les url générées par l'application sont toutes erronées. En effet, un bug fait que django ne tiens pas compte de la variable SCRIPT_NAME. C'est bien dommage, mais un bon vieux hack permet de fixer le problème relativement facilement. Il suffit d'initialiser le PATH_INFO en le précédent du SCRIPT_NAME et le tour est joué.

Voici le résultat:

# -*- coding: utf-8 -*-
import os
from paste.deploy.config import ConfigMiddleware
from django.core.handlers.wsgi import WSGIHandler

def factory(global_config, **local_config):
  os.environ['DJANGO_SETTINGS_MODULE'] = 'jobsafpyorg.settings'
  conf = global_config.copy()
  conf.update(**local_config)
  app = ConfigMiddleware(WSGIHandler(), conf)
  def django_app(environ, start_response):
    environ['PATH_INFO'] = environ['SCRIPT_NAME'] + environ['PATH_INFO']
    return app(environ, start_response)
  return django_app

On peut ensuite se servir de cette usine comme point d'entrée et l'utiliser dans un fichier de configuration paste. Notez que le ConfigMiddleware est indipensable. Le handler de django semble renvoyer des choses peu ordinaire de type class, parfois. Le middleware permet de corriger tout cela.

Problème, si on veut plusieurs instance django dans un seul environnement wsgi, ça devient problématique. Comment initialiser plusieurs configuration avec une seul clé du dictionnaire environ... Je me le demande.

Cela dit, c'est un problème auquel je vais être confronter car j'aimerais fair cohabiter les deux applications django qui ont été faites pout l'AFPy. Donc, la suite au prochaine épisode.

J'y ai fait une conférence sur le WSGI. Ça à au moin eu le mérite de me faire réaliser que j'étais un bien piètre orateur. Probablement que l'AFPYro de la veille n'as rien fait pour arranger les choses, hin hin. En tout cas, j'espère que ça suscitera quelque vocations.

Je suis personnellement convaincu de l'intérêt de cette norme. Et j'ai maintenant un exemple concret à fournir. En effet, je bosse depuis plusieurs mois sur la nouvelle interface de gestion des membres de l'AFPy. Une petite application en Pylons qui permet d'administrer les utilisateurs de notre annuaire ldap et les inscription dans le Zope et les listes de diffusions. Elle est ici, pour ceux que ça intéresse. J'avais aussi fait une petite application compatible WSGI pour pouvoir afficher les photos avec un tag AFPy que les gens posent sur flickr. On avait aussi besoin d'un nouveau WIKI dans le cadre de la refonte du site. Le but était donc de brancher tout ce petit monde dans le site actuel. Heureusement, il y a findus^WWSGI.

Le paquet wsgi.afpy.org était né. Ça donne un petit fichier de configuration sympa qui dessers ces trois applications via un urlmap. Bien sur, le tout est géré avec zc.buildout, ce qui permet d'avoir un environnement python avec les paquets qui vont bien et de faire de l'administration ldap dans un shell python. Un exemple:

>>> from afpy.core import ldap
>>> user = ldap.getUser('gawel')
>>> user
<User dn:uid=gawel,ou=members,dc=afpy,dc=org>
>>> user.email
'gawel@afpy.org'
>>> ldap.getMembersOf('bureau')
[u'tarek', u'ogrisel', u'gwen', u'gawel', u'jpcw2002', u'ccomb']

C'est quand même super fun !!!

Historique

J'avais déjà présenté Django l'année dernière et j'avais vraiment eu l'impression de passer à côté de ma conf. Outre le fait que j'étais bien crevé d'avoir mis en ligne django-fr, j'ai relevé 3 gros défauts :

• je voulais que la présentation serve aussi pour les personnes souhaitant la consulter en ligne, au final c'est beaucoup trop verbeux et le code distrait à mon avis l'auditoire qui vient à une conférence pour s'enrichir d'une expérience et non pour une lecture de code ;
• je voulais faire plaisir à tout le monde en partant de la base pour aller vers des techniques plus avancées et au final personne n'y trouve vraiment son compte ;
• je voulais garder le public connecté et j'ai le sentiment d'avoir été plutôt ennuyeux : c'était long et ça manquait tout simplement de vitalité (sans compter quelques soucis avec S5).

Partant de ce constat, j'ai essayé cette année de :

• faire des slides minimaliste, l'objectif était qu'ils soient tout simplement inutiles sans moi (d'où le besoin de les enrichir pour vous les présenter maintenant, pas sûr que ce soit bon pour moi ça :p), c'est à mon avis le seul moyen de se focaliser sur l'expérience du présentateur et donc sur le message à faire passer ;
• scinder en deux sessions débutant/avancé pour laisser le choix au visiteur de n'assister qu'à la conférence qui l'intéresse ;
• trouver un moyen de rendre les confs plus vivantes (et utiliser Keynote).

Alors pari réussi ? Mon retour personnel après chaque conférence ci-dessous. J'essaye de retrouver ce que j'ai dit de tête, ça sera forcément différent des vidéos qui devraient arriver plus tard : moins de stress, davantage de temps pour étoffer et des liens en bonus.

Pourquoi Django ?

Je n'ai jamais eu de cours de marketing et je hais les commerciaux donc c'est vraiment une épreuve pour moi de « vendre mon produit ». J'ai surtout voulu aller à l'essentiel pour pouvoir ensuite en débattre pendant les questions/réponses.

Avant de parler de Django, il est bon de rappeler les intérêts d'un framework web face à l'approche plus traditionnelle par applications fonctionnelles toutes prêtes. Qu'est-ce qui a pu suscité un tel engouement ?

On connaît tous des projets qui commencent avec un projet tout simple (je prends souvent l'exemple du blog car il est assez parlant). Il existe des trillions de moteurs de blog et il est donc aisé d'en prendre un tout fait :

Mais bien (trop) souvent, un projet évolue en cours de route et l'ajout de fonctionnalités (galerie de photos, paiement en ligne, inclusion de vidéos) aboutit finalement à un cahier des charges ressemblant plutôt à :

Si vous êtes parti d'un simple moteur de blog rafistolé, il est très probable que vous arriviez à un résultat de piètre qualité :

La solution est de partir d'une approche plus bas niveau : la caisse à outil qui va vous permettre de construire vos propres briques fonctionnelles et de réaliser un projet de manière cohérente et évolutive.

De cette façon, vous allez énormément gagner en agilité, la clé de voûte de la qualité (du projet), de la sérénité (du développeur) et de la satisfaction (du client).

Maintenant que vous êtes convaincu du bien fondé des frameworks web, il est temps de passer au plat de résistance : pourquoi Django ?

Django est écrit en Python et vous permet d'écrire du Python, il n'y a pas de fichiers de configuration en xml (ai-je besoin de rappeler que ce format est fait pour les machines ?).

Django est très facile à prendre en main, il suffit de quelques heures (même sans connaître initialement Python) pour avoir une première application qui tourne et en comprendre les principaux concepts.

Face aux deux approches : framework glue vs. réinvention de la roue, Django a choisi la seconde ce qui apporte une cohérence à tous les niveaux (documentation, code, aide, etc) au détriment de sa modularité intrinsèque.

La documentation est un réel atout, surtout lorsqu'on débute. C'est l'une des meilleures documentation technique que je connaisse et elle est en train d'être encore améliorée !

Je suis assez mal placé pour parler de rapidité de développement avec la refonte de ce blog qui a pris... du temps. Néanmoins, pour l'utiliser quotidiennement, je peux affirmer que le développement avec ce framework permet de concrétiser plus rapidement des projets. L'un des atouts est par exemple de prototyper des applications en des temps records, après bien sûr les détails prennent plus de temps, comme partout.

L'interface d'administration auto-générée est vraiment utile et participe à l'« effet Wow !© » initial. Difficile de s'en priver ensuite.

L'échappement des caractères html par défaut peut être un élément important pour une personne débutant en développement web. Ce choix est une réelle sécurité si vous ne maîtrisez pas vraiment toutes les failles possibles d'un code (même s'il serait bon de vous renseigner à ce sujet si c'est le cas !).

Django est simple, autant dans ses concepts que dans leurs mises en application, si vous connaissez Python, vous pouvez même sans peine plonger dans le code de Django et découvrir quelques pépites.

La maturité est souvent un facteur décisif d'un point de vue professionnel, après 5 ans de développement, le framework est devenu stable et à énormément gagné de son ouverture en Open-Source (pour ceux qui se demandent ce qu'une litière pour chat vient faire ici, c'est un jardin zen, j'ai pas trouvé mieux).

Quelques chiffres issus de la présentation de l'année précédente, on voit bien la progression en terme d'utilisateurs et donc de contributeurs potentiels.

Enfin, l'avantage d'avoir des outils à sa disposition est de pouvoir laisser s'exprimer sa créativité, le plus important est ce que l'on fait avec ses outils. Vous pouvez prendre le meilleur des frameworks, ça ne vous assurera pas une application à succès. Ça serait bien trop facile sinon ;-).

Après avoir vanté autant de qualités, voyons pour quels projets cette caisse à outils s'applique.

Il n'y a pas d'outil miracle, notre métier est un éternel compromis et il faut savoir faire avec. L'avantage de Django est qu'il permet de couvrir un très large périmètre d'applications mais si vous voulez construire un gratte-ciel il va peut-être falloir penser à autre chose.

Cela dit, il y a un très faible pourcentage de projets web qui doivent en arriver là et il sera toujours temps de changer certaines parties ou d'améliorer les performances le moment venu.

On termine avec un peu de teasing...

On ne l'attend plus mais Django 1.0 arrive ! (si si, je vous assure) La première branche importante (queryset-refactor) a été mergée au trunk.

Et la suivante (newforms-admin) est en cours de finitions actives. Ce n'est plus qu'une question de ... (mettez ce qui vous semble le plus crédible et votez sur whendjangowillreleaseonepointzero.com).

Des fois que le message n'ait pas été assez clair (j'adore les photos de gens qui sautent dans les présentations, je trouve ça kitsch au possible ;-)).

Bilan personnel

Difficile d'enchaîner une nuit trop alcoolisée courte (il faut croire que c'est une malédiction) et d'insuffler suffisamment de vitalité. Je suis néanmoins assez satisfait car je pense avoir bien fait passer le message qui était tout simple : essayez Django !

L'exemple initial était assez fort pour capter directement l'attention, la liste des avantages était assez claire. Bon par contre je suis conscient qu'il y a du progrès à faire au niveau de la conclusion car je n'ai pas assez insisté à l'oral sur l'intérêt d'avoir une simple caisse à outils pour laisser s'exprimer sa créativité et je voulais insister là-dessus.

Je me suis permis quelques trolls un peu douteux sur Zope 3 (un peu la chance d'avoir assisté à la conf dessus la veille, un peu car on en a parlé une bonne partie de la nuit), je suis pas vraiment sûr que ça avait sa place. Quoi qu'il en soit, les éléments de comparaison cités dans la discussion qui a suivie étaient intéressants.

Django : performances et qualité

J'ai eu beaucoup plus de mal à préparer cette présentation car elle était très dépendante du public. Je voulais éviter de ne m'adresser qu'à une poignée de personnes et j'ai donc choisi au final une approche plus généraliste sur les bonnes pratiques web, appliquées à Django.

Un rapide sondage m'a montré que ce choix était pertinent et que me craintes étaient fondées. Moins d'un quart de la salle avait déjà essayé Django, et une poignée sur de gros projets. Adaptation à chaud : il valait mieux passer du temps sur les aspects pas trop pointus... quitte à décevoir ceux qui étaient venus pour l'intitulé de la conf !

Un rappel préalable sur le coût de la qualité et des performances s'impose. C'est un investissement dans une logique qui s'inscrit dans la durée, ce n'est pas forcément adapté à tous les projets et ça doit être mis en place d'un commun accord entre les acteurs du projet (les tests sont très difficiles à facturer).

Un titre qui claque, je suis sûr qu'en anglais ça rend encore mieux.

Il existe de nombreux outils de détection, du simple module logging à ceux permettant de stresser votre application et votre architecture.

Avant d'optimiser, il faut bien évaluer la situation, il ne sert à rien d'optimiser un site qui ne rencontre pas de problèmes de performances, privilégiez plutôt l'expérience utilisateur (ergonomie, etc). Si vous n'avez pas le temps d'optimiser, vous pouvez toujours avoir une expansion horizontale dans un premier temps (plus de serveurs) si vous disposez des fonds nécessaires. J'ai oublié de parler de l'évolution vers les clouds pour gérer ce type de problématiques.

On entre dans le vif du sujet.

Le cache est l'élément le plus simple à mettre en œuvre et il existe différents niveaux avec Django (page, fragment, vue, queryset, etc) qui permettent d'avoir la modularité nécessaire. Attention, il ne faut pas oublier d'avoir des mécanismes d'invalidation du cache ! (pas comme sur ce blog par exemple...)

Le cache est bien pratique mais insuffisant parfois. Lorsqu'on arrive sur des gros projets, il est quasi illusoire de vouloir s'en tenir à des données normalisées. Ne serait-ce que pour le nombre d'items, il faut avoir recours à des champs dénormalisés. Django dispose de signals pour gérer ça de façon automatisée.

De nombreuses choses peuvent être faites en asynchrone (envoi de mail, préchargements de widget coûteux, etc), AJAX peut ici prendre tout son sens.

Il faut bien faire la différence entre ce qui est imputable à Django et ce qui concerne l'architecture de votre projet, un bon admin sys et/ou DBA peut faire des miracles. Il ne faut pas oublier non plus que les performances css/js jouent un rôle important à ce niveau...

Une petite astuce propre à Django, l'utilisation du tag {% with %} pour créer des alias dans les templates lorsqu'une méthode coûteuse est évaluée dans une boucle par exemple.

Le traitement des performances se fait de manière itérative, essayez de toujours identifier le facteur limitant de la réactivité de votre application.

Un résultat est important, que ce soit un échec ou pas (le scientifique reprend le dessus), pensez à documenter vos essais, que ce soit pour votre équipe ou de manière publique (blog, djangosnippets, etc).

Un autre titre jemelapètegrave.

La pérennité d'une application web est toute relative, l'évolution technologique est telle qu'il est difficile d'être pertinent à plus de 3 ans. Ça veut dire qu'il faut quand même rester évolutif jusque là !

Les règles qui s'appliquent ici sont les mêmes que pour un projet Python, il est impératif de tester les différentes fonctionnalités grâce aux unittests et doctests. Django dispose d'un module entier consacré à ça, il est temps de s'en servir. Un client spécifique aux tests permet même de tester les différentes vues et le résultats des appels (GET, POST, etc).

En découplant les différentes applications de votre projet (lire à ce sujet l'excellent post de James Bennett), vous allez pouvoir vous constituer (ou récupérer) un bibliothèque d'applications web réutilisables dans plusieurs de vos projets.

On ne mentionnera jamais assez à quel point la documentation d'un projet est importante. Normalement les doctests doivent permettre de « raconter une histoire », développez vos talents d'écrivain !

Cerise sur le gâteau, Django vous permet de générer automatiquement la documentation à partir du code dans l'interface d'administration, ce qui s'avère très pratique si vous travaillez avec une équipe de plusieurs personnes dont certaines s'occupent exclusivement du html/css/js.

Exemple d'itération sur l'implémentation des URL.

Utilisation assez naïve avec la construction d'URL à la main, c'est une mauvaise pratique car vous devez modifier les URL à de nombreux endroits si vous décidez de changer votre schéma.

La seconde méthode s'appuie sur une méthode du modèle (différente ici du bien connu get_absolute_url car on veut accéder au profil et non à l'utilisateur), c'est déjà mieux mais il faut encore modifier l'URL à deux endroits en cas de modification.

Enfin la bonne méthode est d'utiliser les URL nommées, qui permettent de ne dupliquer la création des URL à aucun endroit, si vous modifiez celle dans urls.py ça va impacter sur l'ensemble des URL de votre site. Cela est permis grâce au décorateur permalink.

Ces différentes pratiques vous permettent d'opérer des refactoring important de code tout en étant serein et de vous concentrer sur d'autres fonctionnalités.

Je voulais terminer sur un point qui me semble capital pour améliorer la qualité d'une application (pas forcément Django).

L'idée m'est venue en consultant la présentation de Cameron Moll et plus spécifiquement le slide comparant le bon designer au super designer.

J'en suis arrivé à la conclusion qu'un bon développeur est consciencieux, il connaît ses outils et sait parfaitement obtenir un résultat satisfaisant avec. Qu'est-ce qu'il lui manque alors ?

Bien souvent la curiosité, celle de fureter pour finalement trouver une solution plus adaptée ou un module qui fait déjà ce qu'il a mis une semaine à coder, celle d'aller à des conférences, de lire des livres, d'essayer de comprendre pourquoi certaines choses ont été faites ainsi. Cette qualité vous permet de vous épanouir quotidiennement dans votre travail.

Bon avec tous ces conseils, vous allez forcément faire une appli qui va conquérir le monde, faire chuter l'action Google et sauver la planète.

Les crédits, merci ! (complètement illisibles, il faut que je trouve un moyen simple de formater ça)

Bilan personnel

Je suis beaucoup moins satisfait de ma seconde prestation, j'ai remis en question chaque concept présenté au fur et à mesure, doutant de l'intérêt pour quelqu'un s'intéressant peu à Django. Du coup j'étais un peu hésitant et je pense que ça s'est ressenti.

Au final, j'ai un peu le sentiment que ceux qui connaissaient pas trop ces problématiques se sont ennuyés et ceux qui y étaient confrontés aussi car je ne suis pas allé assez loin...

Concernant Keynote (ça vaut pour les deux confs) : aucun problème au niveau des images, par contre je n'ai pas pris le temps de configurer l'écran pour voir le slide suivant + le temps sur l'écran et c'était un tort car ça aide beaucoup.

Conclusion

Il y a probablement des formats plus appropriés pour aborder les problématiques de performances/qualités comme des tables rondes ou des séances de questions/réponses comme me le suggérait Fabien par mail. Pour montrer la rapidité de développement de Django et donner envie d'essayer, rien ne vaut un atelier avec un petit projet de mise en bouche. Autant de pistes qu'il faudra explorer lors des journées 2009 !

Vous y étiez ?

Votre avis m'intéresse énormément. J'aimerais vraiment pouvoir progresser à ce niveau et vous êtes le mieux placé pour m'aider. J'ai déjà eu des retours par blog (merci Sunny), par email et sur irc mais si vous avez un peu de temps, n'hésitez pas, je prends le bon mais aussi et surtout le mauvais. N'ayez pas peur d'y aller trop fort, j'encaisse derrière :-).

[Edit] : les vidéos sont en ligne ! Merci l'AFPy.

La lisibilité est importante

Les programmes doivent être écrits pour être lus par des gens et accidentellement exécutés par les machines.

-- Abelson & Sussman, Structure and Interpretation of Computer Programs

Essayez de rendre vos programmes faciles à lire et évidents.

PEP 8 : Style Guide pour le code Python

Une lecture immanquable : http://www.python.org/dev/peps/pep-0008/ (PEP = Python Enhancement Proposal)

Un PEP est une document procurant des informations à la communauté Python, ou décrivant une nouvelle fonctionnalité de Python et ses processus ou de son environnement.

La communauté Python a ses propres standards sur ce à quoi doit ressembler le code, codifiés dans le PEP8. Ces standards sont différents de ceux des autres communautés, comme C, Java, etc.

L'indentation et les espaces étant si importants en Python, ce Style Guide est une standard. Il est important que vous adhériez au guide ! La plupart des projets suivent ces conventions.

Whitespace 1

• 4 espaces par niveau d'indentation.
• Pas de tabs.
• Ne jamais mixer des tabs et des espaces.
• Un saut de ligne entre les fonctions.
• Deux sauts de ligne entre les classes.

Whitespace 2

• Ajoutez un espace après ", ", dans les dictionnaires, les listes, les tuples, les arguments d'une liste d'arguments et après ":" dans les dictionnaires mais pas avant.
• Mettez des espaces autour des assignements et des comparaisons (excepté pour les arguments d'une liste).
• Pas d'espace aux ouvertures/fermetures de parenthèses ou juste avant une liste d'arguments.

• Pas d'espace en ouverture/fermeture de docstrings.

  def make_squares(key, value=0):
      """Return a dictionary and a list..."""
      d = {key: value}
      l = [key, value]
      return d, l
  

Nommage

• joined_lower pour les fonctions, méthodes et attributs
• joined_lower ou ALL_CAPS pour les constantes
• StudlyCaps pour les classes
• camelCase seulement pour suivre des conventions pré-existantes
• Attributs: interface, _internal, __private

Mais essayez d'éviter la forme __privée. Je ne l'utilise jamais. Faites moi confiance. Si vous l'utilisez, vous le regretterez plus tard.

Longues lignes et continuité

Garder une taille de ligne inférieure à 80 caractères.

Utilisez la continuité implicite des lignes au sein des parenthèses/crochets/accolades :

def __init__(self, first, second, third,
             fourth, fifth, sixth):
    output = (first + second + third
              + fourth + fifth + sixth)

Utilisez les backslashs en dernier recours :

VeryLong.left_hand_side \
    = even_longer.right_hand_side()

Les backslashs sont locaux, ils doivent terminer la ligne sur laquelle ils sont. Si vous ajoutez un espace après le backslash, ça ne sert à rien. Ah aussi, c'est laid.

Longues chaînes de caractères

Les chaînes de caractères adjacentes sont concaténées par le parser:

>>> print 'o' 'n' "e"
one

Les espaces entre les chaînes ne sont pas requis, mais aident à la lisibilité. Tous les types de quotes sont utilisable :

>>> print 't' r'\/\/' """o"""
t\/\/o

La chaîne précédée par "r" est une chaîne de type "raw". Les backslashs ne sont pas évalués comme étant des caractères d'échappement dans les chaînes de type raw. Elles sont utiles pour les expressions régulières et les chemins de fichiers Windows.

Notez que les chaînes de caractères nommées ne sont pas concaténées :

>>> a = 'three'
>>> b = 'four'
>>> a b
  File "<stdin>", line 1
    a b
      ^
SyntaxError: invalid syntax

Cela vient du fait que la concaténation automatique est une fonctionnalité du parser/compiler Python, pas de l'interpréteur. Vous devez utiliser le signe "+" pour concaténer des chaînes de caractères à l'éxecution.

text = ('Long strings can be made up '
        'of several shorter strings.')

Les parenthèses autorisent la continuité implicite des lignes. Les chaînes de caractères sur plusieurs lignes utilisent les triple quotes :

"""Triple
double
quotes"""

'''\
Triple
single
quotes\
'''

Dans le dernier exemple ci-dessus (simple triple quotes), notez l'utilisation du backslash pour échapper les nouvelles lignes. Cela élimine les nouvelles lignes en conservant les quotes joliment alignées à gauche. Les backslashs doivent être à la fin de leurs lignes.

Déclarations

Bon :

if foo == 'blah':
    do_something()
do_one()
do_two()
do_three()

Mauvais :

if foo == 'blah': do_something()
do_one(); do_two(); do_three()

Les espaces et l'indentation sont de bons indicateurs visuels du flot du programme. L'indentation de la seconde ligne du "Bon" ci-dessus montre au lecteur que quelque chose va se produire, alors que le manque d'indentation dans le "Mauvais" exemple cache le "if".

Les déclarations multiples sur une même ligne sont une torture. En Python, la lisibilité compte.

Docstrings et Commentaires

Docstrings = Comment utiliser le code

Commentaires = Pourquoi (rationnel) et comment le code fonctionne

Les docstrings expliquent comment utiliser le code et sont là pour les utilisateurs de votre code. Quelques usages :

• Expliquer le but d'une fonction même si ça vous semble évident car ça ne semblera pas forcément évident à une personne plus tard.
• Décrire les paramètres attendus, les valeurs retournées et les exceptions levées.
• Si la méthode est fortement couplée à un seul appelant, mentionner la fonction appelante (attention au fait que celle-ci puisse changer).

Les commentaires expliquent pourquoi et sont pour les mainteneurs de votre code. Examples incluant des notes pour vous-même, comme :

# !!! BUG: ...

# !!! FIX: This is a hack

# ??? Why is this here?

Les deux types sont de votre ressort donc écrivez de bonnes docstrings et de bons commentaires !

Les docstrings sont utiles pour un usage interactif (help()) et pour les systèmes d'auto-documentation.

Les commentaires et docstrings faux sont pire que tout. Donc conservez les à jour ! Lorsque vous effectuez des modifications, assurez vous que les commentaires et les docstrings sont cohérents avec le code.

Il y a un PEP entier consacré aux docstrings, PEP 257, "Docstring Conventions".

La pratique a raison de la théorie

Il y a toujours des exceptions. Issu du PEP 8 :

Mais plus important : sachez être pertinents - parfois le style guide ne s'applique pas. Lorsque vous avez un doute, utilisez votre raison. Étudiez d'autres possibilités et décidez de ce qui vous semble le mieux. Et n'hésitez pas à demander ! Deux bonnes raisons de ne pas suivre une règle particulière :

(1) Lorsque appliquer la règle va rendre le code moins lisible, même pour quelqu'un qui est habitué à lire du code qui suit les règles.

(2) Pour être cohérent avec du code préexistant qui enfreint aussi ces règles (peut-être pour des raisons historiques) -- même si c'est aussi une opportunité pour faire un peu de nettoyage (dans un pur style XP).

... mais la pratique ne doit pas réduire la théorie à néant !

On plonge maintenant au cœur du tutoriel : les astuces. On va commencer avec les plus faciles et augmenter progressivement le niveau.

Variables intermédiaires

Dans les autres langages :

temp = a
a = b
b = temp

En Python :

b, a = a, b

Vous l'avez peut-être déjà rencontré mais savez vous comment ça fonctionne ?

• La virgule est la syntaxe de construction du tuple.
• Un tuple est créé à droite (tuple packing).
• Un tuple en est la cible à gauche (tuple unpacking).

La partie à droite est unpackée dans les noms de tuple de la partie à gauche.

D'autres exemples:

>>> l =['David', 'Pythonista', '+1-514-555-1234']
>>> name, title, phone = l
>>> name
'David'
>>> title
'Pythonista'
>>> phone
'+1-514-555-1234'

Utile dans les boucles sur des données structurées (la variable l ci-dessus a été conservée) :

>>> people = [l, ['Guido', 'BDFL', 'unlisted']]
>>> for (name, title, phone) in people:
...     print name, phone
...
David +1-514-555-1234
Guido unlisted

Chaque item de people est unpacké dans le tuple (name, title, phone).

Il est aussi possible de faire le chemin inverse, il faut juste s'assurer d'avoir la même structure à droite et à gauche :

>>> david, (gname, gtitle, gphone) = people
>>> gname
'Guido'
>>> gtitle
'BDFL'
>>> gphone
'unlisted'
>>> david
['David', 'Pythonista', '+1-514-555-1234']

Aller plus loin avec les tuples

On a vu que la virgule était le constructeur du tuple, pas les parenthèses. Par exemple :

>>> 1,
(1,)

L'interpréteur Python montre les parenthèses pour que ce soit plus clair et je vous conseille de faire de même :

>>> (1,)
(1,)

Mais n'oubliez pas la virgule !

>>> (1)
1

Dans un tuple contenant un seul élément, la virgule est nécessaire. Dans un tuple avec plus de 2 éléments, la virgule finale est optionnelle. Pour un tuple vide, une paire de parenthèses suffit :

>>> ()
()

>>> tuple()
()

Une erreur de typo courante est de laisser une virgule alors que vous ne souhaitez pas avoir un tuple. Il est très facile de l'oublier dans votre code :

>>> value = 1,
>>> value
(1,)

Donc si vous vous retrouvez avec un tuple alors que vous ne vous y attendiez pas, cherchez la virgule ! (Note du traducteur : de ma propre expérience, il est plus courant d'oublier la virgule pour un tuple ne contenant qu'un seul élément, dans les settings de Django par exemple, cherchez plutôt la virgule manquante dans ces cas là).

Le "_" interactif

C'est une fonctionnalité très utile que peu de développeurs connaissent. (Note du traducteur : bien entendu vous n'en faites pas partie et vous connaissez les dangers associés.)

Dans un interpréteur interactif, que vous évaluiez une expression ou que vous appeliez une fonction, le résultat est stocké dans une variable temporaire, _ (un underscore) :

>>> 1 + 1
2
>>> _
2

_ stocke la dernière valeur affichée.

Lorsqu'un résultat vaut None, rien n'est affiché, donc _ ne change pas. C'est normal !

Ça ne marche que dans un interpréteur interactif, pas dans un module.

C'est particulièrement utile lorsque vous travaillez sur un probl