Le blog à Fred

J'ai donc récupéré une petite application relativement objet qui inclue :

• du PyGtk pour l'interface graphique,
• des threads,
• des appels ZMQ via PyZMQ,
• et des accès à une base de données PostgreSQL via SQLAlchemy

Pfiouu !! tout ça pour mon premier projet en Python, c'est la classe.

Je peux donc maintenant critiquer facilement ce langage

Mais commençons d'abord par être gentil.
Finalement, coder en Python a un petit côté agréable que je comparerais aisément au plaisir du développement des petits scripts en Shell.
Autre avantage du langage, la foule de bibliothèques pour faire tout et n'importe quoi, ce qui n'existe pas en Shell.
Puisque je suis gentil, j'ajouterai aussi l'orientation objet du langage^[1].
Enfin, parce qu'il faut bien s'arrêter un jour dans les compliments, la syntaxe n'est pas étrangère pour les vieux cons comme moi qui ont commencé en C^[2].

Bon, ça suffit de sourire béatement sur la beauté du Python.
Le Python, c'est un serpent. En plus, ce n'est pas un serpent spécialement inoffensif quand on est une souris.
Par contre, les insectes^[3] ne sont pas dans son régime alimentaire.
Et bien, voilà, après avoir commencé à apprivoiser le serpent, je me suis rendu compte de plusieurs choses:

• il est insondable.
• il est imprévisible. Il faut vraiment attendre le dernier moment pour savoir ce qu'il va faire.
• il faut une patience d'ange pour s'en occuper

Premier point, l'insondabilité du bidule.
Je m'explique pour ceux qui n'auraient pas suivi. Je ne suis pas l'auteur du programme dont j'ai maintenant la garde.
Jusqu'à il y a peu, j'étais assez tranquille, pas de remontée de bugs donc pas de correction à faire. Mais il y a quelques semaines, une petite dizaine de bugs et demandes d'évolutions me sont tombées dessus^[4].
L'auteur initial ayant commis ce forfait étant parti^[5], j'ai donc dû me baser sur la transmission de savoir faite il y a maintenant 4 mois.
Franchement, retomber dans un code Python de plusieurs milliers de lignes, c'est pas facile.
Bien que le code soit assez bien architecturé, l'absence de types reste, pour moi, un énorme problème. En effet, dans ce cas, seul le nom de variable permet de savoir de quoi on parle.
Exemple :

def startEditContent(self, side, order, step)

Alors ? Side, c'est quoi ? Il y a bien une énumération, enfin, une classe qui parle de ça mais est-ce bien ça ?
Pour Order, là, pas de bol, il n'y a rien donc ça doit être un truc atomique genre entier.

Au final, il n'y a pas 36 techniques, il faut retrouver tous les appels à cette méthode pour voir comment elle est appelée.
Là, on se dit que l'on va être aidé par son IDE, dans mon cas PyDev sous Eclipse.
En fait, oui mais non. Enfin, moi, j'ai pas trop réussi et hormis faire une recherche plein texte, je n'ai pas trouvé de moyen d'afficher la hiérarchie des appels d'une fonction.
Par contre, dans l'autre sens, ça a l'air de fonctionner. Conclusion je dois pas être doué.

Deuxième point, l'imprévisibilité.
Là, je vais être beaucoup plus rapide.
Une fois que l'on a compris plus ou moins ce que c'est censé faire, après de longues heures d'analyse et de rétro-ingéniérie^[6], on tente sa première modification, la sueur perlant sur les tempes.
Et là, très content, on tente le lancement de l'appli. Comme rien n'est compilé, il faut attendre patiemment de tomber dans le cas où on va passer par le code subtilement développé.
Quand la ou les fameuses lignes arrivent, on croise les doigts pour ne pas avoir fait de faute de frappe sous peine de voir arriver une belle traceback vous annonçant que l'objet sur lequel vous tentez l'opération actionne^[7] ne supporte en rien cet appel.
Bon, ben, c'est pas grave, on recommence et on reteste.

Cela m'amène justement au troisième point, la patience.
Tout comme on parle souvent de la zenitude des développeurs Ruby (cf. là), je me dis qu'il faut aussi être très zen en Python.
En effet, relancer son application sans cesse pour vérifier que le bug est bien corrigé, sans être sûr qu'il ne va pas y avoir toute une quantité de bugs que l'on pourrait éviter par une analyse de types, tient plus de l'acharnement que du génie logiciel.
Alors, oui, on pourra me dire qu'il faut faire des tests unitaires dans tous les sens pour se blinder et éviter les problèmes mais comment on fait quand ça tire un modèle objet long comme un jour sans vin ?
Des mocks ? Dans mon cas, c'est trop compliqué.

En conclusion, si Python peut être intéressant, c'est, à mon humble avis, pour de petits développements ne nécessitant pas énormément de maintenance ou pour les gros développements où le développeur est enchaîné au PC :D