Je continue d'apprendre python et je vous livre quelques unes de mes impressions après 1 mois :

  • Le coup de structurer le programme avec l'indentation, c'est vraiment pas mal. Les fonctions se limitent au strict nécessaire, il n'y a pas de fioritures type {} ou BEGIN END. Finalement on se rend compte que c'est totalement inutile (en tout cas ça ne participe en rien au fonctionnel d'un programme). Par contre, c'est assez déroutant parce que les fonctions, les classes, les if, while et autres structures de contrôle n'ont pas de vrai fin... et je ne m'y suis toujours pas habitué. Du coup, pour terminer une fonction ou une classe, je met un # (le caractère pour les commentaires) devant la dernière ligne.
  • Comme le langage est vraiment souple (comme un basic d'autrefois), j'ai la hantise de la variable mal orthographiée ou déjà utilisée pour autre chose. Il n'y a pas de mécanisme de sécurité, vu que les variables ne sont pas fortement typées (comme en pascal par exemple)
  • J'oublie toujours les ":" après les structures de contrôle, le plus souvent derrière le "else". D'ailleurs, c'est a se demander pourquoi subsiste ce caractère de contrôle... Peut-être pour éviter de prendre le mot clef "else" pour une variable ...
  • J'ai vu aujourd'hui qu'on ne peux pas mettre, dans une fonction, de paramètres obligatoires entre des paramètres optionnels. ça parait évident pour le programmeur C, mais c'est tellement souple le python que je ne me suis pas méfié... On dirait que je prends de mauvaises habitudes ;-)
  • Un truc qui me semble tellement évident maintenant que je me demande comment un nouveau langage ne pourrait pas implémenter ce genre de chose. Ce sont les docstrings et les doctests. Kezako ? Alors le docstring c'est une chaine de caractère qui se met derrière la définition d'une classe ou d'une fonction et qui document la fonction. On peut la faire afficher par l'appel à la méthode "docstring" (avec 2 soulignés avant et après) qui l'affiche alors. C'est pratique pour savoir comment marche telle ou telle fonction (ça ma servi pour getopt :). Bon, le doctest, c'est vraiment autre chose, ça s'écrit dans un docstring (parque finalement ça documente des cas d'utilisation) avec une syntaxe particulière. Donc, il s'agit d'écrire des appels à la fonction, avec les paramètres qui vont bien. Quand on a écrit plein de doctests, on écrit un petit bout de programme (python aussi) pour les faire tourner (au alors on fait comme moi, on s'inspire fortement d'un programme déjà existant - merci haypo pour utiliser la GPL 2 sur hachoir ;). Donc, les doctests bien écrit ça permet d'avoir des tests de non régression très facilement. Bon, je n'ai pas encore tout bien compris. Notamment je ne suis pas certain de l'écriture lorsque l'appel à la fonction dépend, avant et après, d'appels à d'autres fonctions. De même je n'ai pas encore bien compris comment je peux faire pour tester un objet en retour de fonction. Je pense que ça viendra avec l'habitude.
  • Y'a bien un truc qui me chagrine, mais je suis persuadé que ce n'est vraiment qu'une question de temps : Le langage change encore beaucoup. J'avais utilisé une jolie clause "with ... as ..." mais par la suite j'ai fait tourner mon programme sur une machine où seul le 2.4.4 est installé et là, ma jolie clause, j'ai été obligé de l'enlever... dommage. Faudra leur dire à tous que le 3 est sorti et qu'il peuvent donc installer des versions plus récentes au moins la 2.6...

Sinon, python, c'est rigolo, c'est comme un bon vieux basic, ça donne envie de programmer, tester, modifier, changer, inventer... Donc si vous ne connaissez pas, ne perdez pas une minutes de plus pour vous y mettre (sinon, vous le regretterez autant que moi !)