J'ai eu le privilège de présenter Django lors des journées organisées par l'afpy. C'était vraiment un weekend exceptionnel, une organisation exemplaire, des conférences de qualité, des discussions de geek, que du bon. Je me suis enfin décidé à mettre les slides en ligne, en attendant les vidéos.

Ça faisait un moment que je n'avais pas parlé des bonnes pratiques Python mais l'approche de Pycon fr (où je présenterai Django : le pourquoi et le comment le 18 mai), l'événement Python incontournable avec un programme des plus alléchants, m'a bien motivé pour effectuer la traduction de l'une des meilleures présentation par David Goodger que je connaisse qui remet les bonnes pratiques Python à plat, ce qui est toujours bon avant d'aller plus loin.

Après être venu à bout du 1000+ de Google Reader, autant partager avec vous mes dernières découvertes car les billets de qualité ont été nombreux au cours de mes vacances. J'ai un peu la flemme de tout classer, au moins vous lirez jusqu'au bout ;-).

J'ai beaucoup de mal à critiquer un livre pour lequel j'ai fait une relecture (c'est la raison pour laquelle je n'avais pas parlé de la seconde édition du livre Ubuntu) car j'ai généralement déjà fait mes remarques à l'auteur avant la parution. En ce qui concerne le Petit guide à l’usage du développeur agile, je me sens obligé d'en parler car je suis trop jaloux de ne pas l'avoir écrit :-).

Voila la solution à laquelle je suis arrivé après avoir testé les solutions existantes : django collection, django crudapi et django restful model views. J'attends beaucoup du GSoC consacré à l'inclusion native de REST dans Django et les choses vont dans le bon sens de ce côté là mais j'avais besoin d'une solution maintenant. Enfin notez bien le une dans le titre qui est très important, il y a énormément d'interprétations de l'architecture REST, cette implémentation essaye de s'inspirer de celle définie dans le livre RESTful Web Services : l'architecture orientée ressource (ROA).

Un petit billet pour signaler que les prochaines journées Python francophones se tiendront les 2 et 3 juin prochains à la Cité des Sciences de la Villette. J'y ferais une présentation intitulée « Tout savoir sur Django » le dimanche après-midi qui pourra être utile à tous ceux qui n'ont pas encore eu l'occasion de faire le grand saut ou qui sont tout simplement curieux.

Un article intitulé « Python web development and frameworks in 2007 » très intéressant que j'aurais aimé traduire fait le bilan sur le développement web python et ses principaux frameworks, de web.py à Zope, en passant par Django, Pylons et TurboGears. J'ai appris de nombreuses choses donc je vous invite à aller le lire sur place mais c'est vrai que c'est assez long donc en voici un résumé accompagné de mes commentaires.

Pour le boulot, je devais réaliser un prototype implémentant des processus simples, c'est-à-dire représentés par une suite d'étapes ordonnées. On peut facilement se représenter un tel processus en considérant une ligne de métro avec ses stations sans ramifications.

Je viens de tomber sur les snyppets de Seb Sauvage (site que j'apprécie beaucoup par ailleurs) et il y a une phrase qui m'a interpellé sur le paragraphe consacré à zip, map, filter et aux list-comprehensions :

Except that {map|filter} is faster. (than list-comprehensions)

Ni une, ni deux, je récupère l'article de Tarek qui est très bon et qui comporte une fonction testant la durée d'execution des fonctions pour pouvoir comparer. J'avais déjà essayé d'autres fonctions mais autant innover un peu.

Devant le franc succès remporté par le premier opus, au passage merci NiKo, j'ai décidé de faire des analyses plus poussées. Ça m'a donné l'occasion de faire une vraie classe Python et d'obtenir de beaux graphes grâce à matplotlib.

Vous n'êtes pas sans savoir que des données reatives aux utilisateurs d'AOL ont été mises en ligne dernièrement (version anglaise, je pense que les serveurs sont plus régulièrement mis à jour si vous voulez récupérer les données). Voici le script et les 100 premiers mots-clés de recherche réalisées par ces utilisateurs. Attention les données n'ont pas été filtrées donc ce post peut contenir des mots heurtant la sensibilité des plus jeunes lecteurs.

Guido le soulignait il y a quelques temps, Python souffre un peu du manque de promotion. La nouvelle version du site est un premier pas, de « nouvelles » initiatives voient le jour (à quand une telle ressource en français ?!) mais peut-être que les blogs sont un des meilleurs moyen de promotion d'un produit actuellement. Voila donc ma participation, ce ne sont pas forcément les arguments que vous pourrez lire ailleurs, nous n'aimons pas forcément tous les mêmes choses pour les mêmes raisons mais ce sont ceux qui me font apprécier Python aujourd'hui.

Le programmeur est fainéant. C'est ainsi. S'il ne l'était pas, il n'essayerait pas de s'aider d'un ordinateur. Du coup il évite dans la mesure du possible de s'encombrer de variables trop longues, ou d'appels répétitifs un peu trop élaborés. Heureusement, en Python, on peut simplifier tout ça. Mais la simplification peut mener à un manque de lisibilité dans certains cas. Un cas intéressant est celui de l'underscore.

C'est LE livre que j'attendais, un peu comme beaucoup de personnes qui connaissent les bases du langage et qui souhaitent aller plus loin mais qui n'arrivent pas forcément à trouver l'information sur internet. Je dois avouer que j'avais un peu peur, un peu comme un bon film duquel on en attend trop, et bien je n'ai pas été déçu, c'est le moins qu'on puisse dire !

Je m'y prend un peu à l'avance (la sortie est prévue pour septembre 2006) mais Guido a apparement fait quelques annonces lors de Pycon qui viennent s'ajouter aux PEPs approuvés sur la page officielle. J'essayerais de mettre à jour ce billet lors de l'annonce de nouvelles nouveautés histoire qu'il ne soit pas obsolète dans 6 mois, n'hésitez pas à m'en informer.

En réaction au billet de mat qui a codé un convertisseur em vers pixels. Je me demande souvent si la méthode que j'emploie est la plus pertinente pour parser des arguments en ligne de commande lorsque je crée des petits scripts en python. Voici le template que j'utilise souvent, toutes les remarques en commentaire sont les bienvenues !

Dans les épisodes précédents, je m'étonnais de voir des concaténations de chaînes de caractères être plus rapide que des remplissages de listes. Depuis je cogite car il est indiqué un peu partout qu'il faut privillégier les listes. Et j'ai fini par trouver une réponse :-).

À l'intersection entre bonnes pratiques et optimisation comment afficher des chaînes de caractère en Python ? Privillégier la lisibilité ou l'optimisation ? Les deux mon capitaine !

Dans quelles situations utiliser les chaînes de caractère ? Pourquoi pas des listes ? Et les list-comprehension dans tout ça ? Réponses en tests, c'est plein de strings mais ne vous inquiétez pas, rien de sexuel ;)

Ça faisait longtemps que je voulais écrire un peu là-dessus et puis le temps tout ça... bref je viens de tomber sur deux billets qui m'ont motivé, apparemment je suis pas le seul à vouloir apprendre/faire partager sur Python. Coïncidence pas si pure que ça, la sortie du livre Programmation Python que j'attends depuis quelques semaines et que je compte acheter à Solutions Linux ou gagner :)

Le jour de l'unification des syntaxes wiki sera un grand jour. Voila le parfait exemple d'un défaut du monde du Logiciel Libre, toujours premiers pour dire qu'il faut appliquer les standards mais pas très doués pour en créer un... enfin bon j'avoue que je suis un peu énervé. Dans le cadre du transfert de certains billets de blogs sur le wiki de documentation d'ubuntu-fr on me demande souvent s'il n'existe pas un convertisseur pour passer d'une syntaxe wiki Dotclear à une syntaxe wiki Dokuwiki, c'est maintenant chose faite.

L'une des galère tâche quotidienne d'un bio-informaticien s'intéressant un tant soit peu à la biologie structurale et à la position d'une protéine dans l'espace est de parser des fichiers PDB. C'est fichiers, issus de la Protein Data Bank, contiennent une foultitude d'informations plus ou moins pertinentes en fonction de son sujet de recherche. Or, les parsers actuels que je connais sont pour la plupart de véritables usines à gaz souvent inadaptés et lourds pour le traitement que j'ai à faire. Voici donc un « squelette » de parser de PDB en python, par « squelette » j'entend que vous allez devoir coder les parties spécifiques à vos besoins.

Si vous n'avez toujours pas trouvé d'aggrégateur satisfaisant, il serait peut-être temps de coder le votre passer votre commande :-)

Je me suis finalement décidé à coder un aggrégateur en python, d'une part pour réaliser un projet intéressant et d'autre part pour avoir des fonctionnalités qui me manquent cruellement, voila une première liste à compléter :

Je vais bientôt être en stage et celui-ci va consister à réécrire un programme qui est en C++ en C puis à l'interfacer avec Python pour enfin proposer ce service sur Internet (simplicité quand tu nous tiens...). Tout ça pour dire qu'il faut que je me mette à Python car le reste c'est normalement de l'acquis (hum).