Mots-clé : python

Développement : Coding contest !

Challenge de codeurs !

C’est pour le fun, essayez vous aussi 

Le principe est simple

Vous aurez deux puzzles de programmation à résoudre.

Pour ce faire, vous pourrez choisir votre langage favori parmi ceux-ci : Java, C, C++, C#, Javascript, PHP, Python, Ruby, Objective-C, Haskell and Go.
La durée moyenne d’un challenge est de 2 heures et 30 minutes.

J’y serai, le 28 septembre !

Gimp et Python-fu script : vecteurs et strokes : exemple

J’ai eu énormément de mal à trouver un exemple de script python-fu qui fonctionne.

Après avoir réussi à automatiser certaines tâches grâce à Gimp, je voulais créer des vecteurs, et y appliquer la brosse en cours.

Voici l’exemple de code qui fonctionne :


  new_image = pdb.gimp_image_new( new_image_width, new_image_height, RGB )
  new_layer = pdb.gimp_layer_new(
    new_image, new_image.width, new_image.height,
    RGBA_IMAGE, _("Background"), 100, NORMAL_MODE)
  pdb.gimp_image_add_layer(new_image, new_layer, -1)
  pdb.gimp_drawable_fill(new_layer, fill_type )
  new_layer = gimp.Layer(
    new_image, _("New Layer"),
    new_image.width, new_image.height,
    RGBA_IMAGE, 100, NORMAL_MODE)
  pdb.gimp_image_add_layer(new_image, new_layer, -1)
  pdb.gimp_drawable_fill(new_layer, fill_type )

  new_vectors=pdb.gimp_vectors_new(new_image, 'Vectors!')
  t = int(round(step / 1.5))
  pdb.gimp_vectors_stroke_new_from_points(
    new_vectors,
    0, # 0 = Beziers Curve
    30,
    # {controle1} {centre} {controle2}
  [ x-(step-t), y, x-step, y, x-(step-t), y,
      x, y+(step-t), x, y+step, x, y+(step-t),
      x+(step-t), y, x+step, y, x+(step-t), y,
      x, y-(step-t), x, y-step, x, y-(step-t),
      x-(step-t), y, x-step, y, x-(step-t), y],
      False) # Closed = True

  pdb.gimp_image_add_vectors(new_image, new_vectors, 0)

  pdb.gimp_context_set_foreground( (255,255,255) )
  pdb.gimp_context_set_brush( "Circle (07)" )
  pdb.gimp_edit_stroke_vectors(new_layer, new_vectors)

  gimp.Display( new_image )

Maintenant avec cet exemple, si vous voulez faire des vecteurs et les dessiner avec la brosse en cours, ainsi qu’avec mon article sur l’automatisation de Gimp, vous devriez arriver à faire beaucoup de choses !

Python et autohotkey : exemple concret

C’est en cherchant des airs connus que je suis tombé sur ce site : http://www.mutopiaproject.org/ qui recense toutes les compositions tombées dans le domaine publique, qui a généré en automatique des fichiers midi en conséquence, et, surtout, qui a utilisé un logiciel du domaine publique extrêmement performant qui a constitué toutes les partitions.
Comme il y en a des centaines, et que tout est organisé de la même façon, je me suis fait un « aspirateur » de ces compositions, et puis, une fois aspirées, je me suis généré un fichier AutoHotKey (cf http://www.autohotkey.com/), logiciel tout simplement extraordinaire avec lequel on peut simuler en script absolument tout ce qu’on veut sous Windows : souris et clavier. J’ai donc « préposté » tous les articles que vous pouvez voir, et j’en fais apparaître un sur deux « réellement » à moi. Comme ça je fais d’une pierre deux coups : je promeus un site extrêmement bien fait et gratuit, et j’alimente mon blog (ces articles se sont étalés sur quatre mois).

Peut-être que cela vous donnera des idées ? 😉

Python, débutant et jeu : Soko-ban version geek

Avez-vous déjà entendu parler de Sokoban, le jeu ?
J’ai eu la formidable idée (c’est de l’humour…) de le coder en Python, et encore mieux (c’est encore de l’humour…) de le coder pour pouvoir y jouer en mode console.

\o/

J’ai commencé à développer pour qu’il soit international, donc les commentaires sont pour la plupart en anglais.

La première chose que je voulais faire c’est pouvoir faire des affichages différents. Donc, selon que votre console le supporte ou pas, vous pourrez changer l’affichage :

# Different drawings:
glob_tab_chars = \
[
    # Ground / GroundStoneDest / Wall / Player / Stone
    [ ' ', '.', '█', '☺', '☻', '○','♦' ],
    [ ' ', '.', '#', '@', '+', '$','*' ],
    [ ' ', '.', '░', '☺', '☻', '○','◙' ]
]

Voici l’écran de base :

Copie d'écran de PySoko

Voici l’écran, si on veut changer les graphismes (en cliquant sur « + » ou sur « -« ) :
Copie d'écran de PySoko

Voici l’écran, si on veut encore changer les graphismes (en cliquant sur « + » ou sur « -« ) :
Copie d'écran de PySoko

Le code orienté objet

Les classes de base

Et ensuite le plus important à mon sens : le code orienté objet. J’ai voulu apprendre l’orienté objet de python. J’ai donc crée des classes qui correspondent aux objets de base (dans l’ordre, classe du Sol sans rien, classe du Sol où il faut ranger une pierre, classe Mur, et classe Joueur) :

# Different drawings:
class Ground(object):
    def __init__(self):
        super(Ground,self).__init__() # Parent call:

class GroundStoneDest(object):
    def __init__(self):
        super(GroundStoneDest,self).__init__() # Parent call:

class Wall(object):
    def __init__(self):
        super(Wall,self).__init__() # Parent call:

class Player(object):
    def __init__(self):
        super(Player,self).__init__() # Parent call:

Classe Level

Et de la même façon j’ai crée la classe Level qui est la plus complexe, et qui contient les fonctions les plus utilisées :

  • apply_drawings_set()
    Calculer les motifs pour dessiner le tableau (oui, oui c’est plus complexe que ça n’en a l’air) ;
  • draw()
    Dessiner les motifs en cours à l’écran ;
  • register_player_move()
    Se souvenir des mouvements du joueur, soit pour pouvoir faire un « undo » (pas implémenté), soit pour pouvoir les sauver pour les rejouer (pas implémenté non plus) ;
  • move()
    Essai de déplacer un objet situé en (x,y) du décalage (add_x, add_y), sachant que le décalage peut être négatif ;
  • solved()
    Test si toutes les pierres sont bien rangées.

Classe LevelsReader

De la même façon, j’ai crée la classe LevelsReader qui lit un niveau, et l’analyse pour voir s’il est un minimum cohérent. Pas la peine d’entrer dans le détail, les fonctions sont suffisamment explicites je pense.

Bibliothèque curses

Et pour terminer, la fonction de la boucle principale qui concerne l’unité curses : def curses_main(stdscr, code). C’est ici qu’on affiche le menu, qu’on attend qu’on tape sur une touche, etc.

Notez bien : le code n’est pas terminé. C’est un début de code, relativement correctement fait. J’ai passé à peine deux jours dessus pour réussir à faire cela, donc ne m’en voulez pas trop, il n’est pas peaufiné, mais il fonctionne.

Si jamais vous l’améliorez, ce serait gentil de me faire parvenir la nouvelle version 🙂

Le lien que tout le monde attend avec impatience, la bave aux lèvres :

Cliquez ici : pysoko.tar.bz2

Python : exemple simple socket, gethostbyaddr et nom de domaine

Ci suit un exemple simple. Supposons que vous venez tout juste d’acheter le domaine « p-bor.com » mais vous avez beau faire un ping, rien ne fonctionne, parce que malgré que vous l’ayez acheté, il n’est toujours pas actif. En pratique, vous devez attendre et revenir de temps à autre essayer de le « pinger » pour voir si, enfin, vous arriver à le voir sur Internet.
J’ai une solution plus amusante : il suffit de faire ce script python, qui essaie de faire la correspondance entre une adresse « nom de domaine » et son adresse IP.
C’est la fonction gethostbyaddr().
Dès que la correspondance est faite, on l’affiche et on quitte. Dit autrement, tant que votre nom de domaine n’est pas validé, il y aura une boucle de test toutes les minutes. Surtout n’hésitez pas à laisser un commentaire pour améliorer la chose !


#!/usr/bin/env python
# -*- coding: utf-8 -*-
import socket, time, random

random.seed()
nom_de_domaine = 'cuts-coiffure.fr'
Ok = False
while Ok == False:
    try:
        print nom_de_domaine+' => '+ \
            str(socket.gethostbyaddr(nom_de_domaine)[0])+ \
            ' ==> Valide !'
        Ok = True
    except socket.gaierror as E:
        tm_year,tm_mon,tm_mday, \
        tm_hour,tm_min,tm_sec, \
        tm_wday,tm_yday,tm_isdst = \
        time.localtime()
        print "%04d-%02d-%02d / %02d:%02d:%02d : %s." % \
            (tm_year,tm_mon,tm_mday, \
            tm_hour,tm_min,tm_sec,str(E))
        time.sleep(60 + random.randint(1, 90) )

bazaar : tutoriel, et exemple concret d’utilisation

Je fais quelques petites notes personnelles au fur et à mesure de l’utilisation de Bazaar, au cas où cela serve à quelqu’un :

La première chose, la plus importante à savoir, pour les non-anglophones :

Du point de vue de bazaar, « checkout«  signifie « faire un lien entre« .

Par exemple :

  • on fait un lien entre deux répertoires A et B (« bazaar checkout A B »)
  • pour toute validation de modification avec bazaar (« bazaar commit » ou autre), que ce soit sur A ou sur B, bazaar va aussitôt les répercuter de l’autre côté (sur B ou A).

(1) Créer un dépôt « central » distant qui hébergera TOUS les projets

Ici, dans « /rep_bazaar/iwn_bazaar/ » :

> bzr init-repo --no-trees \
    sftp://bazaar@serveur_ftp/rep_bazaar/
bazaar@serveur_ftp's password:
Shared repository (format: 2a)
Location:
  shared repository: sftp://bazaar@serveur_ftp/rep_bazaar/
>

(2) Créer un projet distant : ici, le projet est « projet_web« 

– D’après la config précédente, il faut le créer dans une branche du dépôt central = « /rep_bazaar/projet_web/ » :

> bzr init sftp://bazaar@serveur_ftp/rep_bazaar/projet_web
bazaar@serveur_ftp's password:
Created a repository branch (format: 2a)
Using shared repository: sftp://bazaar@serveur_ftp/rep_bazaar/
>

(3) En local, initialiser un répertoire ‘vide’ qui sera celui de référence à partir duquel toutes les branches futures (dev, preprod et prod, etc.) vont dériver

(!!) dans la ligne de commande, il y a le répertoire distant ET un répertoire destination, ici « website_reference » :

> mkdir website_reference
> bzr  \
    checkoutsftp://bazaar@serveur_ftp/rep_bazaar/projet_web \
    website_reference

Attention !

D’après ce que j’ai compris, il ne faut pas toucher aux sources de références, parce qu’elles vont être copiées sur les environnements de dev, preprod et prod.

(4) Ajouter les fichiers source dans le répertoire de référence :

> cp -R website/* website_reference/

(5) Dire à bazaar d’ajouter tous les fichiers :

> cd website_reference/
~/website_reference # bzr add
(
Énorme liste de fichiers :
adding blabla/blabla.png
..
adding drupal/blabla/..
...
adding drupal/.../blabla.gif
)

(6) Valider les modifs en local avec un commentaire pour le dépôt #1 :

~/website_reference # bzr commit -m "Fichiers originaux"
(
Énorme liste de fichiers :
adding ...
..
added ws/blabla.php
...
added xml/xx/blabla.xml
)
~/website_reference #

(!!) On peut donner en local un nom différent du nom de la branche distante !

Mais comme ça risque de devenir rapidement le bazar (ahah), j’ai choisi de donner des noms identiques au répertoire du dépôt distant et aux répertoires locaux :

(7) Création de la branche de développement sur le dépôt distant :

> bzr branch sftp://bazaar@serveur_ftp/rep_bazaar/projet_web \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/dev

(8) Lier la branche distante à un répertoire local

(!) je répète : on peut donner en local un nom différent du nom de la branche distante, mais je pense que c’est à éviter, donc :

> mkdir projet_web
> mkdir projet_web/dev
> bzr checkout \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/dev \
    projet_web/dev
bazaar@serveur_ftp's password:
>

(9) Création de la branche de préproduction :

Deux mêmes ordres que pour la branche de développement (sauf répertoire final) :

> bzr branch \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/preprod
> bzr checkout \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/preprod \
    projet_web/preprod
bazaar@serveur_ftp's password:
>

(9) Création de la branche de production :

Deux mêmes ordres que pour la branche de développement (sauf répertoire final) :

> bzr branch \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/prod
> bzr checkout \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/prod \
    projet_web/prod
bazaar@serveur_ftp's password:
>

(10) Arrivé ici, le schéma est ainsi :

Sur le site de dépôt commun, mais aussi en local :

projet_web
  |
  +--- dev
  |
  +--- preprod
  |
  +--- prod

(11) Créer les sous-branches pour les développeurs :

> bzr branch \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/dev \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/dev/autre_dev
> bzr branch \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/dev \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/dev/olivier

(12) Arrivé ici, le schéma est ainsi :

Sur le site de dépôt commun :

projet_web
  |
  +--- dev
  |     |
  |     +--- autre_dev
  |     |
  |     +--- olivier
  |
  +--- preprod
  |
  +--- prod

NB : en local, les branches n’ont pas été créées, donc en local c’est ainsi :

projet_web
  |
  +--- dev
  |
  +--- preprod
  |
  +--- prod

(13) Exemple personnel : ma branche de développement pour la cellule médicale v 2.0 :

Nb : on crée encore une branche distante, rien n’est encore fait en local :

> bzr branch \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/dev/olivier \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/dev/olivier/nouveau_developpement

(13) Arrivé ici, le schéma est ainsi :

Sur le site de dépôt commun :

projet_web
  |
  +--- dev
  |     |
  |     +--- autre_dev
  |     |
  |     +--- olivier
  |            |
  |            +--- nouveau_developpement
  |
  +--- preprod
  |
  +--- prod

NB : en local, les branches n’ont pas été créées, donc en local c’est ainsi :

projet_web
  |
  +--- dev
  |
  +--- preprod
  |
  +--- prod

A partir de maintenant, on peut refaire en local toutes les branches qui n’y sont pas encore (autre_dev, olivier, nouveau_developpement).

Mais je choisis, par exemple, de ne faire que mes branche locales à moi (= olivier) :

Je fais le lien (= checkout) entre olivier et olivier distant :

>bzr checkout \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/dev/olivier \
    projet_web/dev/olivier

Je fais le lien (= checkout) entre nouveau_developpement et nouveau_developpement distant :

>bzr checkout \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/dev/olivier/nouveau_developpement \
    projet_web/dev/olivier/nouveau_developpement

(14) Résultat final :

Sur le site de dépôt commun :

projet_web
  |
  +--- dev
  |     |
  |     +--- autre_dev
  |     |
  |     +--- olivier
  |            |
  |            +--- nouveau_developpement
  |
  +--- preprod
  |
  +--- prod

En local, certaines branches n’ont pas été créées (volontairement) donc en local c’est ainsi :

projet_web
  |
  +--- dev
  |     |
  |     +--- olivier
  |            |
  |            +--- nouveau_developpement
  |
  +--- preprod
  |
  +--- prod

A partir de maintenant, en pratique

En pratique, il me suffit : de travailler sur le répertoire nouveau_developpement puis de faire toutes mes modifs, mes évolutions.

Une fois que je pense que tout est bon :

  • Aller dans le répertoire nouveau_developpement
  • Faire un commit :
    bazaar commit -m "Commentaire mise à jour"
  • Automatiquement, les modifications vont être répercutées sur ma branche distante (= sur le site de dépôt commun).

pygame : exemple de transparence

Voici un exemple simple pour gérer la transparence : cet exemple est très simple, il crée un petit carré qui suit la souris partout, et un autre « gros » carré qui apparait autour de la souris puis ne bouge plus, et dès que la souris sort de ce carré, hop, il fait un fondu au noir. Vous pouvez donc vous baser sur cet exemple pour comprendre comment transformer votre Surface en surface transparente destinée à être rapidement affichée à l’écran. Je parle de convert_alpha(). Avec cet appel, pour vous donner une idée, le temps pris est presque 40 fois plus rapide que sans l’appel. Vous pouvez tester par vous même !

Attention !
Le plus important c’est de faire dans l’ordre :

        self.image.set_alpha(valeur_transparence)
        pygame.Surface.convert_alpha(self.image)

Car l’ordre self.image.set_alpha(valeur_transparence) fera créer un masque au complet, et ce n’est qu’après qu’il vous faudra convertir la totale via pygame.Surface.convert_alpha(self.image).

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import os, pygame, sys, time, random, copy, pprint
from pygame.locals import *

class MySprite(pygame.sprite.Sprite):
    def __init__(self,width,height):
        # (!) Avant toute chose appeler le constructeur parent :
        pygame.sprite.Sprite.__init__(self)
        self.width = width
        self.height = height
        self.rect  = pygame.Rect(0, 0, width, height)
        self.image = pygame.Surface( (self.rect.width, self.rect.height) )
        self.image.set_colorkey((0,0,0))
        self.image.fill((0, 0, 0))

class SMouse(MySprite):
    def __init__(self,width,height):
        MySprite.__init__(self,width,height)
        pygame.draw.rect(self.image, (205,250,130), self.rect, 5)
        self.image = self.image.convert()

    def update(self):
        self.rect.topleft = pygame.mouse.get_pos()

class Contour(MySprite):
    def __init__(self,width,height,speed):
        MySprite.__init__(self,width,height)
        pygame.draw.rect(self.image, (105,250,230), self.rect, 5)
        self.fadeout = False
        self.speed = speed
        self.alpha = 250
        self.done = False
        self.image.set_alpha(self.alpha)
        # Convertir en transparent :
        pygame.Surface.convert_alpha(self.image)

    def update(self):
        if not self.fadeout:
            if not self.rect.collidepoint( pygame.mouse.get_pos() ):
                self.fadeout = True
        else:
            self.alpha -= self.speed
            if self.alpha<0:
                self.alpha = 0
                self.done = True
            self.image.set_alpha(self.alpha)

def main():
    pygame.init()
    pygame.mouse.set_visible(0)
    screen = pygame.display.set_mode( (0,0),
        pygame.FULLSCREEN | pygame.DOUBLEBUF | pygame.HWSURFACE )
    if pygame.display.Info().bitsize < 24:
        print "This game needs a 24 bits display"
        pygame.quit()

    background = pygame.Surface(screen.get_size())
    background = background.convert()
    background.fill((0, 0, 0))
    screen.blit(background, (0, 0))
    pygame.display.flip()
    clock = pygame.time.Clock()
    c = Contour(500, 500, 5)
    c.rect.center = pygame.mouse.get_pos()
    group_sprites = pygame.sprite.RenderPlain( [ SMouse(50, 50), c ] )

Clonage en Php et en Python

Php fournit une super méthode méga géniale qui donne la possibilité de dupliquer des objets : le clonage.
Waaaaaaaaaah \o/

http://www.php.net/manual/en/language.oop5.cloning.php

Bah seulement y’a comme un petit hic : si les propriétés sont elles-même des objets, alors il faut les cloner à la main. Dit autrement, comme la plupart des propriétés sont des objets, autant faire un

X = new Objet();
Y.assignTo(X);

Et voilà on se l’est fait le clonage parce que la méthode assignTo() est aussi longue à écrire que d’écrire la routine « __clone() ». Donc en fait leur méthode de merde elle est comme le H de Hawaï.

Alors que je suis en train de voir… la méthode existe en Python et elle est exactement ce qu’il me faudrait (=deepcopy()) ici http://docs.python.org/library/copy.html .

Je pense que je ne peux pas éviter Php pour tout ce qu’il y a déjà en place dans le monde d’Internet mais ça me fout vraiment, vraiment les bouboules. J’ai vraiment raison quand je dis qu’en Python on développe en gros deux fois plus vite qu’en Php.

>_<

Python : mes premiers essais

Bon, sur cet article ici, j’ai traduit tout le vécu d’un auteur, et j’ai voulu tester par moi même.

En pratique, j’ai installé un dictionnaire de Français entièrement gratuit, et je voulais récupérer les mots Français, sans la définition (je ne dirai pas pourquoi par contre hahahah).

Donc je regarde les fichiers, c’est du XML.
Ok donc il me faut juste un parseur.
En Delphi, ça m’aurait pris disons… une trentaine de minutes.
Eh bien pour mon premier script en Python, ça m’a pris… 10 minutes.
Oui oui je n’exagère pas : 10 minutes, j’ai lancé le chrono pour voir si j’allais être rapide ou pas.
Voilà mon script :

1 #! /usr/bin/env python
2 # -*- coding: utf-8 -*-
3
4 # r = open('/datas/dictionnaire/test
5
6 import types, fileinput
7
8 def process(line):
9 if line[0:7] == ' 0):
12 sub = sub[:sub.find(' ')]
13 if (sub.find(',') > 0):
14 sub = sub[:sub.find(',')]
15 print(sub)
16
17 for line in fileinput.input():
18 process(line)

Incroyable. Effectivement, en pratique c’est vraiment ce que j’ai mis sur mon article précédent : tout est clair, lisible, la documentation aide bien, et c’est extrêmement rapide, en tous les cas sa rapidité suffit amplement pour faire toutes les tâches de scripts de base que l’on veut.

Je suis extrêmement content, à part depuis la découverte de la librairie ExtJs, qui est très impressionnante, ça allait faire longtemps que je n’avais pas été autant enthousiasmé (du point de vue informatique, j’entends).

Débutants : pourquoi le langage Python ?

J’ai fait cette traduction, vous pourrez trouver l’article d’origine ici.

Pourquoi Python ?

Par Eric Raymond

Le cardinal Biggles a gardé Eric au confessionnal pendant quatre heures avant d’entendre cette confession…
La première fois que j’ai dû me pencher sur Python… c’était par pur accident. Et je n’ai pas vraiment apprécié ce que j’ai vu à ce moment là. C’était début 1997, et le livre sur la programmation Python de Mark Lutz (O’Reilly & Associates) venait tout juste de sortir. Parfois les livres O’Reilly arrivent sur le pas de ma porte, en suivant un processus complètement aléatoire pour lequel j’ai abandonné tout essai de compréhension.
L’un deux était « Programmation Python ». Comme je collectionne les langages de programmation, j’ai trouvé cela intéressant. Je connais déjà une bonne douzaine de langage génériques, j’ai écrit quelques compilateurs et des interpréteurs pour le fun, et j’ai déjà designé quelques langages qui avaient des objectifs spécifiques et qui devaient suivre un certain formalisme. Récemment j’ai d’ailleurs écrit SNG, un langage écrit spécifiquement pour manipuler des images PNG (Portable Network Graphics). Les lecteurs intéressés peuvent regarder la page en question ici : http://www.catb.org/~esr/sng/. J’ai aussi écrit quelques implémentations de vieux langages, vous pouvez voir ça sur ma page du musée de la rétro-programmation (« Retrocomputing Museum page ») ici : http://www.catb.org/retro/.
Concernant Python, j’avais juste entendu que c’était un langage de « scripting », donc un langage destiné à écrire des scripts, avec son propre gestionnaire de mémoire intégré, et de grandes facilités pour appeler et coopérer avec d’autres programmes. Je me suis donc plongé dans « La Programmation Python » avec une idée bien précise en tête : que fait Python que Perl ne peut pas faire ?
Perl, bien sûr, était le poids lourd des langage modernes de scripting (NDT : c’était en 2000). Il est souvent devenu le langage de prédilection pour les administrateurs système en lieu et place du langage de scripting shell, souvent grâce à sa librairie UNIX et ses appels système, et aussi grâce à sa collection énorme de modules Perl construits par une communauté Perl très active. En 2000, ce langage est estimé être à l’origine de 85% du contenu « live » que l’on peut trouver sur le Net. Larry Wall, son créateur, est souvent considéré, à juste titre, comme l’un des leaders les plus importants dans la communauté Open Source, et apparait souvent en troisième place derrière Richard Stallman, et Linus Torvalds dans le panthéon des hackers demi-dieux.
A cette époque, j’avais utilisé Perl pour plein de petits projets. J’avais trouvé ce langage assez puissant, même si la syntaxe et quelque autres aspects de ce langage semblaient rebutants. Je pensais que Python avait un sacré chemin à faire en tant que nouveau langage de script, et au moment où j’ai commencé ma lecture, je me suis intéressé d’abord à ses aspect qui le rendaient unique.
J’ai fait immédiatement un mauvais trip sur la première chose que tout le monde remarque quand on lit un script Python pour la première fois : le fait que les espaces (= l’indentation) signifie quelque chose dans la syntaxe du langage. Ce langage n’a aucun délimiteur du type des crochets que l’on trouve en C ou en Perl ; au lieu de cela, les changements dans l’indentation délimitent naturellement les groupes. Et, naturellement, comme la plupart des hackers, lorsque j’ai réalisé cet état de fait, je suis retombé immédiatement dans une phase de dégoût.
Je suis suffisamment vieux pour avoir programmé en FORTRAN dans les années 1970. Au jour d’aujourd’hui, personne – ou presque – ne l’a jamais fait, mais le fait de l’avoir fait a mis en tête à ceux qui ont dû « subir » ça, quel point il est énervant de pratiquer le principe de « champs prédéterminés ». En fait, le terme « formatage libre » utilisé pour décrire le nouveau style de langage orienté « mot-clé », par exemple en Pascal et en C, a presque été oublié ; c’est parce que tous les langages d’aujourd’hui sont basés sur ce principe. Enfin presque tous. C’est difficile de blâmer quelqu’un, si, lorsqu’il voit un code Python, réagit comme s’il avait marché dans une bouse de dinosaure.
C’est un peu ce que j’ai ressenti. J’ai alors lu le reste de la description du langage, sans trouver quelque chose d’autre d’intéressant. Je n’y voyais aucune raison de recommander Python, à part le fait peut-être que la syntaxe semblait un peu plus claire que celle de Perl et qu’il semblait plutôt facile de créer des éléments d’interface utilisateur (« GUI elements ») tels que les boutons et les menus.
J’ai remis le livre sur l’étagère, en pensant qu’il faudrait que je me fasse un petit projet orienté GUI en Python, juste pour m’assurer que j’avais bien compris les fondements du langage. Jamais je n’aurais cru que ce que j’allais voir éclaterait littéralement la compétition avec Perl.
C’est à ce moment là qu’une conspiration de choses inutiles à faire s’est organisée autour de moi, et j’ai mis la priorité de « Test Python » tout en bas de la liste des choses à faire. Cela dura plusieurs mois. Entretemps j’ai même écrit le livre « The Cathedral and the Bazaar ». Mais j’ai tout de même trouvé le temps d’écrire quelques programmes en Perl, dont deux assez gros et complexe. L’un deux, « keeper », est un assistant qui est encore utilisé (NDT : en 2000) lors de soumissions de nouveaux fichiers qui arrivent au gestionnaire d’archives du laboratoire Metalab. Il génère les pages web que vous pouviez voir à metalab.unc.edu/pub/Linux/!INDEX.html. L’autre, « anthologize », était utilisé pour générer automatiquement la documentation PostScript de la sixième édition de l’archive des HowTos du Projet de Documentation Linux. Ces deux programmes sont disponibles à Metalab.
Écrire ces programmes en Perl m’a laissé progressivement un gout amer. Les gros projets semblaient transformer les petites choses ennuyeuses de Perl en problèmes sérieux et récurrents. La syntaxe qui parait simplement un peu excentrique au début, se transforme au bout de plusieurs centaines de lignes en une jungle vierge pratiquement impénétrable, et je ne vous raconte pas quand il s’agit de milliers de lignes. La maintenance devient exponentielle en fonction du nombre de lignes de code. Beaucoup de ces problèmes ont été résolus en ajoutant des patches à Perl (objets, variables locales, « use strict », etc.), mais cela m’avait bien refroidi.
De plus, la résolution de bogues, déjà anormalement difficile à résoudre, se transformait en mission presque impossible si on s’absentait quelques jours pour faire autre chose. Plus le temps passait, plus je me battais avec les problèmes du Perl au lieu de me pencher sur les problèmes de l’application proprement dite. Le pire de tout, c’est que le code devait être sale. C’est simple : des programmes laids et sales sont comme des ponts suspendus : ils ont beaucoup plus de chances de s’effondrer que des ponts classiques, parce que la manière dont nous percevons la beauté (particulièrement les ingénieurs) est intimement reliée à notre capacité de gérer et de comprendre la complexité sous-jacente. Un langage qui empêche, de par sa nature, d’écrire un code élégant, empêche aussi d’écrire un bon code.
Avec une expérience d’une vingtaine de langages dans mes valises, je pouvais distinguer tous les petits signes qui me disaient que j’avais poussé tel ou tel langage jusqu’à ses propres limites. A la mi-1997, je me disais « il doit y avoir une meilleure solution ». Et je me suis mis à rechercher un langage de scripting plus élégant.
Je n’ai même pas imaginé replonger dans le C. Les jours où il semblait censé d’écrire ses propres allocations mémoire et son propre gestionnaire d’allocations sont largement révolus, mis à part certaines niches de développement comme l’écriture de code pour le noyau, le graphisme 3D, bref, des endroits où on doit gagner un maximum de temps machine et par là même un contrôle personnalisé de l’utilisation mémoire.
Dans toutes les autres situations, il est impensable d’imaginer passer du temps en plus, à déboguer les débordements de buffer (buffer overruns), la mauvaise gestion des pointeurs, les fuites mémoire générées par les malloc/free et tous les autres inconvénients liés à cela. C’est bien mieux de se dire que la machine va mettre un peu plus de temps et que le programme va consommer un peu plus de mémoire, et économiser sur le facteur humain. C’est d’ailleurs cette stratégie qui a conduit à l’explosion de Perl vers le milieu 1990.
J’ai commencé par tester Tcl, et j’ai rapidement découvert que c’était encore pire que Perl. Le vieux LISPer que je suis s’est alors penché sur les variantes de Lisp et Scheme, mais comme cela l’a été depuis le début pour Lisp, même un bon design est rendu complètement inutile s’il n’existe aucune documentation (ou très peu) sur les liens POSIX/UNIX, et si la communauté est très faible et, de plus, fragmentée. Si Perl est devenu populaire ce n’est pas par accident. La plupart de ses compétiteurs étaient simplement plus mauvais.
La seconde fois où je me suis penché sur Python était aussi accidentelle que la première fois. En octobre 1997, j’ai reçu plein de questions sur « fetchmail », la plupart venant d’utilisateurs basiques, qui montraient clairement qu’ils avaient des difficultés à générer des fichiers de configuration pour mon utilitaire « fetchmail ». La configuration du programme utilise une syntaxe classique, du style UNIX, mais peut devenir extrêmement compliquée à partir du moment où un utilisateur a des comptes POP3 et IMAP sur plusieurs sites. Par exemple, voici un fichier de configuration : Listing 1.
J’ai alors décidé d’écrire un éditeur facile à appréhender, pour aider à la configuration : « fetchmailconf ». L’objectif était clair : cacher complètement la complexité de la syntaxe derrière une interface utilisateur simple, claire et conviviale, avec des boutons de sélection, et des fiches simples à remplir.
Rien que l’idée de faire ça en Perl me faisait peur. J’avais déjà vu du code GUI en Perl, et c’était un vague mélange de Perl et de Tcl qui était encore plus laid au final que mon propre code Perl. C’est à ce moment là que je me suis souvenu de Python, que j’avais à peine survolé six mois auparavant. C’était le moment ou jamais.
Bien sûr, l’objectif allait sûrement tester sévèrement mes compétences en tant que personne inexpérimentée dans ce langage. La première chose que j’ai revue était cette fameuse indentation. Cette fois néanmoins j’ai passé outre, et j’ai commencé à taper un code grossier pour faire quelques éléments GUI. Aussi bizarre que cela puisse paraitre, après une vingtaine de minutes, ce procédé d’indentation ne m’a plus du tout paru anormal. J’ai juste indenté comme je l’aurais fait en C, sans me poser plus de question, et ça a fonctionné.
C’était ma première surprise. La seconde est venue après plusieurs heures de codage du projet, lorsque j’ai remarqué durant mes « va-et-viens » entre le programme et le livre sur Python, que j’écrivais du code pratiquement aussi vite que je le tapais. Lorsque j’ai réalisé cela, j’ai été comme électrifié. Si on y pense bien, une grosse partie de l’effort du codage correspond à tous les moments où lorsqu’on veut résoudre un problème, cette résolution ne s’écrit pas comme on se la représente mentalement. Et on met toujours beaucoup de temps à réaliser que ce que l’on a écrit ne correspond pas forcément à la résolution du problème. Ce principe aide énormément à mesurer la qualité d’un langage : lorsque vous apprenez un langage, combien de fois il vous a fallu ré-écrire une portion de code tant que vous ne connaissiez pas bien ce langage.
Lorsque vous écrivez un code qui fonctionne presque aussi vite que vous le tapez, vous ne revenez pratiquement jamais en arrière, et en général cela signifie que vous maitrisez parfaitement ce langage. Mais ce n’était pas du tout logique, parce que c’était mon premier jour de Python et je faisais régulièrement des pauses pour regarder, dans le livre, les appels à faire aux différentes librairies !
C’est le premier indice qui m’a fait penser que Python avait un design exceptionnellement bon. La plupart des langages ont des spécificités et des choses si particulières à apprendre qu’il faut toujours énormément de temps avant de pouvoir bien les maitriser. Python était le premier langage qui invalidait ce principe.
J’ai mis très peu de temps avant de comprendre des particularités. J’ai écrit « fetchmailconf », avec GUI, en six jours, dont deux ont été utilisés pour apprendre Python lui-même. Cela reflète une autre propriété utile de ce langage : il est compact. Vous pouvez avoir toutes ses caractéristiques facilement et rapidement en tête (tout au moins son concept et ses librairies de base). C est un langage connu pour être compact. Perl est connu pour ne pas l’être. On a beau dire ce qui a fait le succès de Perl : « Il n’y a pas qu’une seule manière de l’écrire », dans tous les cas, ce n’est jamais concis.
Le moment le plus dramatique de ma découverte était encore à venir. Mon design avait un problème : il était facilement possible de générer un fichier de configuration, mais après, lorsqu’il fallait mettre les mains dans ce fichier de configuration on retombait à nouveau dans le problème d’origine.
Le parseur du fichier de configuration de « fetchmail » est plutôt élaboré. Pour tout dire, il est écrit en YACC et Lex, deux outils classiques UNIX qui sont utilisés pour générer le code C d’un parseur. Pour que « fetchmailconf » puisse éditer des fichiers de configuration existants, je me suis dit que je devais faire un parseur fonctionnant à l’identique en Python. Je n’en avais pas du tout envie, d’une part à cause de tout le travail que cela impliquait, et d’autre part parce que je n’étais pas sûr que les comportements allaient être de manière fiable absolument identiques. C’était bien la dernière chose dont j’avais besoin : du boulot supplémentaire pour tenir à jour deux parseurs en même temps lors des futures évolutions de « fetchmail ».
Ce problème m’a bloqué pendant quelque temps. Puis j’ai eu une inspiration subite : je vais laisser « fetchmailconf » se servir du parser de « fetchmail » ! J’ai alors ajouté l’option –configdump à « fetchmail » afin qu’il puisse parser un fichier « .fetchmailrc » et en sortir un fichier sous la forme d’un initialiseur Python. Voici un exemple de fichier qu’il était possible de sortir : Listing 2 (pour gagner de la place un peu d’information pas liée au sujet a été supprimée).
Python pouvait évaluer la sortie de la commande « fetchmail –configdump ».
Ce n’est pas fini ! Je ne voulais pas que « fetchmailconf » puisse lire la configuration courante, mais je voulais la transformer en arbre d’objets dynamiques. Il devait y avoir trois types d’objets dans cet arbre :

  1. Configuration (l’objet de plus haut niveau qui représente toute la configuration)
  2. Site (objet qui représente entièrement l’un des sites)
  3. User (les données d’un utilisateur particulier rattachées à un site)

Le fichier d’exemple précédent décrit cinq objets « Site », chacun ayant un objet « User » rattaché à lui.
J’avais déjà écrit ces trois classes d’objets (c’est ce qui m’a pris quatre jours, pendant lesquels j’ai surtout passé du temps à mettre les objet GUI à la bonne place). Chaque classe avait une méthode qui pouvait faire surgir un pop up d’édition qui éditait les données de l’objet proprement dit. Il ne me restait plus qu’à transformer les données lues d’origine en objets réels.
J’ai tout d’abord imaginé écrire du code qui connaitrait les informations de chaque classes et utiliserait ces connaissances afin de faire une correspondance, mais j’ai rapidement oublié cette idée, parce qu’en imaginant ajouter des nouveautés il y aurait des problèmes de compatibilité.
Ce que je voulais vraiment c’était un code qui analyserait la forme et les membres de l’initialiseur, en demandant directement au code qui définissait les classes, et qui s’ajusterait automatiquement afin de faire concorder les données d’un côté et les objets de l’autre.
Ce genre de choses est appelé « bidouille de méta-classes » (« metaclass hacking ») et est souvent considéré comme quelque chose d’ésotérique et d’effrayant (de la magie noire). La plupart des langages « orienté-objet » n’ont pas cette capacité ; pour ceux qui le peuvent (Perl y compris), cela a tendance à rendre le code plutôt complexe et dur à appréhender. J’avais déjà été impressionné par la rapidité d’apprentissage de Python mais là on arrivait à un vrai test. Quelle complexité de code est-ce que cela allait engendrer ? Je savais par expérience que cela allait être difficile, et même en arrivant à mes fins, le résultat allait être sale. J’ai tout de même pris le livre et je me suis penché sur les capacités Python concernant les méta-classes. La fonction résultat est dans le Listing 3, et le code qui l’appelle est dans le Listing 4.
Ça n’a pas l’air super compliqué soi-disant pour de l’affreuse magie noire, pas vrai ? Trente deux lignes en comptant les commentaires. En sachant juste ce que j’ai dit sur la structure de la classe, le code appelant est compréhensible. Mais ce n’est pas la taille qui est vraiment impressionnante. Tenez-vous bien : il m’a fallu quatre-vingt-dix minutes pour écrire ce code, et il a fonctionné correctement la première fois où je l’ai testé.
Dire que j’étais épaté est un euphémisme. Rien que le fait d’avoir un code qui fonctionne dès la première écriture est déjà remarquable en soi ; mais en plus, c’était ma première bidouille avec des méta-classes, six jours après avoir appris le langage ! Même en essayant d’imaginer que je suis un sacré bon hacker, ça n’en resterait pas moins une preuve vivante de la clarté, de la concision, et de l’élégance du design de Python.
C’est bien simple : il n’y a aucune possibilité simple de faire cela en Perl, même avec mon expérience plutôt poussée avec ce langage. C’est à ce moment là que j’ai réalisé que c’en était fini de Perl.
C’était un moment très intense. Bon, j’avoue qu’avec du recul, on peut juste constater que ce n’était qu’une bidouille subtile et élégante rendue possible grâce la souplesse de Python. L’utilité à long terme d’un langage ne se trouve pas que dans la possibilité, justement, de faire des bidouilles subtiles, et élégantes, mais aussi dans l’utilité qu’on a du langage au jour le jour. Le travail au jour le jour ne consiste pas qu’à écrire de nouveaux programmes, mais principalement à en lire et à en modifier des existants.
La vraie conclusion de cette anecdote est celle-ci : plusieurs mois après avoir écrit « fetchmailconf », je pouvais toujours lire et comprendre mon code sans avoir de gros effort de concentration pour tout comprendre à nouveau. Je stresse déjà rien qu’en imaginant avoir à replonger dans le code de « keeper » ou « anthologize » à nouveau, mais « fetchmailconf » ne pose aucun problème.
Perl a toujours son utilité. Pour des petits projets (100 lignes ou moins) qui impliquent énormément de filtres de texte (« pattern matching »), je pense que je pencherai peut-être vers une bonne expression régulière Perl plutôt que du code Python. En regardant les scripts « timeseries » et « growthplot » Perl de la distribution « fetchmail », je peux dire que ce sont presque des choses qu’on pourrait faire en utilisant une bonne combinaison de awk/sed/grep/sh. Pour tout le reste, je préfère de loin les vertues de Python, je pense que si vous testez, vous en arriverez certainement à la même conclusion.