Les secrets d'un code pythonique

Tout le monde se secoue !

J'ai commencé (jeudi 21 janvier 2016 à 12h33) la rédaction d'un article au doux nom de « Les secrets d'un code pythonique » et j'ai dans l'objectif de proposer en validation un texte aux petits oignons. Je fais donc appel à votre bonté sans limite pour dénicher le moindre pépin, que ce soit à propos du fond ou de la forme. Vous pourrez consulter la bêta à votre guise à l'adresse suivante :

Merci !

Je pense que plusieurs sections pourraient être encore bien complétées, mais je préfère ouvrir tôt ce premier jet, pour commencer à obtenir des retours.

Bonne idée !

Tu pourrais mentionner les outils qui aident à obtenir un code pythonique (par exemple, Pylint).

J'ai lu très en diagonal, mais j'ai une remarque importante sur la partie Exemples : tous ceux qui ont déjà donné des cours te le diront, si tu dis « faites A, ne faites pas B », les deux tiers des gens feront B (parce qu'ils connaissaient déjà, parce tu as mis l'emphase dessus…).

Je te conseille de ne présenter que les bonnes manières de faire en exemple, de bien insister dessus, et de ne parler des mauvais exemples que de manière rapide, générique et si possible positive (préférer les listes en intention aux boucles, et les boucles for aux while, laisser python gérer les compteurs…). Bref, traiter la partie exemple de la même manière (pédagogiquement parlant) que la partie Les mécanismes du langage.

Vayel> Oui c'est une bonne idée, je les mentionnerai.

Gabbro> D'accord, je ne voyais pas du tout les choses comme ça, je vais alors retravailler le tout.

Salut,

Les parenthèses n'aident pas trop pour comprendre le terme.

"Ça" désigne quelque chose qu'on voit, quelque chose de précis qui a été désigné. Instinctivement, je dirais "quelque chose" mais je trouve que ça ne sonne pas très bien.

En français, "à jamais" est une expression. La première fois que j'ai lu la phrase, j'ai compris "maintenant est préférable, et ceci pour toujours". Une proposition qui sonne (encore une fois) moins bien que la tienne : "Maintenant est mieux que jamais.".

Aussi, tu peut peut-être introduire la PEP 8 en disant que le code est bien plus souvent lu que écrit, ce qui explique cette recherche de la lisibilité.

"et ce dans tous les cas", non ?

Pour les liens dans la partie "La bibliothèque standard", tu ne peux pas les intégrer dans le texte ? Pareil pour la partie d'après.

Tutoriel très intéressant pour n'importe quel débutant Python. (tleb $\in$ population cible)

Très sympathique sur le fond. J'aime un peu moins la forme, le tutoriel ne fait que rappeler les principes de Python et y ajouter quelques exemples à la fin (très intéressants cependant).

Je connais presque par cœur la PEP20, le principe du DRY, mais il me manque des exemple concret pour savoir appliquer chaque points des ces "règles". Les exemples à la fin n'apporte qu'une vision globale peu utile sans explications précises ou exemples points par points.

tlbe> Je vais essayer de voir ça.

the_new_sky> L'idée serait donc plutôt d'intégrer les exemples à chacune des sections ?

Oui, tout en les expliquant d'avantage quitte à ajouter des exemples.

« Mieux vaut maintenant que jamais. ».

vieux motard que j'aimais.

• un code idiomatique (en accord avec les idiomes du langage)

je suis pas mal d'avis de virer toute référence au mot "idiome". A part jargonner inutilement je ne vois pas ce que ce mot apporte. L'idée c'est de dire "coder de manière à ce que le résultat soit compréhensible de toute personne ayant l'habitude de coder en python". Un exemple simple : alors qu'en java on aime bien vérifier que certaines conditions sont vérifiées afin de ne pas lancer d'exception, en python on préfère demander au programme d'agir de suite et d'attraper toutes les exceptions possible. Ainsi, pour un développeur python, un simple

1
2
3
4

try:
    open("file", "wb")
except Excpetion:
    pass

paraîtra bien plus compréhensible que

1
2

if os.path.isfile("file") and os.path.canwrite("file"):
    open("file", "wb")

Oui, donc tu proposes de remplacer un mot simple « idiomatique » par sa définition « compréhensible de toute personne ayant l'habitude de coder en python »… Je ne trouve pas que ça simplifie. Par contre, il faudrait effectivement définir ce qu'est un idiome, ce n'est pas un mot très courant. Parce qu'actuellement, le mot « idiomatique » est défini comme « ce qui respecte les idiomes »… Pas très éclairant.

Je ne trouve pas que ça simplifie.

en quoi remplacer une expression compréhensible de tous par un mot connu de personne (c'est schématique) simplifierait les choses?

Donc pour moi peu importe comment tu vas tourner ça, mais la famille de "idiome" est juste un vecteur de complexification et de branlette intellectuelle.

À un moment donné, tu dois savoir donner des noms aux choses. Si tu veux t'amuser à utiliser uniquement les 1000 mots les plus utilisés de la langue française et reformuler toutes tes phrases en conséquence, libre à toi. Si tu veux tenter l'expérience, je te gâche le plaisir de la découverte : ton propos sera difficilement compréhensible.

Il y a une différence entre rendre clair le propos et complexifier une phrase pour éviter un mot qu'il serait facile de définir. Voilà un exemple :

• Phrase alambiquée : « coder de manière à ce que le résultat soit compréhensible de toute personne ayant l'habitude de coder en python ».
• Phrase épurée : « coder en respectant les règles d'usages de Python »
• Phrase cryptique : « un code idiomatique (en accord avec les idiomes du langage) »
• Phrase avec définition : « écrire un code idiomatique, c'est-à-dire respectant les règles d'usages de la communauté Python ». Ensuite, on peut réutiliser le mot idiomatique à loisir.

Tu vois où je veux en venir ? Tu remplaces « respectant les règles d'usages » par « idiomatique ». Niveau complexité syntaxique, il y a une grande différence.

On n'est pas ici dans un cadre littéraire, ni dans un cadre de discussion entre experts. On est dans le cadre d'une transmission d'une connaissance/d'une compétence.

Plus tu places la barre haute en matière de vocabulaire, plus tu rends cet objectif difficile à atteindre.

QU'il y ait un peu de jargon est normal. Mais bon, voilà ce qu'on a aujourd'hui :

• le mot "idiom" arrive dès l'introduction qui elle est extrêmement courte. Il est donc mis en exergue pour du vent puisque là on veut juste introduire le sujet.
• on a les règles général du ZoP : cool mais ils sont eux mêmes jargonneux :
  • "Les espaces de noms sont une sacrée bonne idée, utilisons-les plus souvent" => quand tu as un niveau basique en python, tu n'as peut être vu qu'une seule fois les espaces de noms: quand tu as utilisé argparse
  • "Les cas spéciaux ne le sont pas assez pour briser les règles" => un "cas spécial" c'est quoi par rapport au contexte du ZoP? Une suite de if/elif? Un cas où on ne respecterait pas le ZoP?
  • "Le plat est préférable à l'imbriqué" => "plat"? "imbriqué"? ça veut dire qu'il faut faire des sous-fonctions?

Bref on jargonne pour ne rien dire. On est là pour apprendre aux gens. Il est toujours préférable de donner la définition puis de l'associer au mot que de donner le mot puis de mettre entre parenthèse/note bas de page/ encart spécial la définition. Il faut que les gens comprenne la notion. C'est ça le but.

Le mot "idiome" ne sert à rien.

Je n'aime pas la manière dont j'introduis et cite la PEP20, c'est juste une traduction sans grand intérêt. Je pense plutôt la détailler point par point, et l'illustrer.

Pour ce qui est du mot « idiomatique », je pense le conserver, il a l'avantage d'exister contrairement à « pythonique ».

Je ne suis pas du tout d'accord avec Gabbro sur l'approche qui consiste à ne pas donner ce qu'il ne faut pas faire.

Si le tutoriel s'adresse à des gens qui connaissent déjà la programmation, et viennent potentiellement d'un autre langage, il me semble au contraire plus opportun de leur montrer les différences entre ce qu'on fait en Python et ce qu'on ne fait pas en Python (mais qui est souvent la manière de faire dans les autres langages). Dans mon cas, je viens du C++ et il y a plein de petites choses que je peux améliorer dans ma manière d'utiliser Python et montrer comment modifier mes habitudes en partant du mauvais vers le bon est probablement le plus simple pour moi parce que je peux identifier clairement ce qui fait le bon et le mauvais.

Il y a toujours une raison sous-jacente de pourquoi c'est mieux comme ça, ce n'est jamais gratuit, et l'expliquer permet tout de suite de modifier ses habitudes pour de bonnes raisons.

Il y a toujours une raison sous-jacente de pourquoi c'est mieux comme ça, ce n'est jamais gratuit, et l'expliquer permet tout de suite de modifier ses habitudes pour de bonnes raisons.

Ça oui.

Dans mon cas, je viens du C++

Justement. Le risque, c'est que tu retiennes (au moins dans un premier temps) la méthode la plus proche de ce que tu connais, par analogie. C'est un magnifique biais cérébrale. Ce qu'il ne faut pas faire en python, car c'est du C++ traduit en python, tu le sais déjà ; en présentant les bonnes méthodes, tu vas tout seul les comparer aux méthodes que tu connais (car ça reste proche, l'objectif est le même…). Bref, tu vas faire l'analogie, mais la mauvaise manière de faire (en python) restera associée au C++ (car c'est de là que viens ton analogie), tandis qui si on te la présentes dans un cours python, tu vas associer la mauvaise manière de faire… à python.

De plus, quelqu'un venant du Java, du C++, du python (débutant) ou du Haskell auront 4 mauvaises manières de faire du python différentes, le mauvais n'est en fait pas unique.

Je suis pas sûr d'avoir été clair, l'idée est que c'est dû à un biais cognitif, donc c'est une façon de faire à éviter. J'ai pas de source fiable à proposer, mais à ma connaissance, il y a une relative unanimité des enseignants à ce sujet.

Tu vas trop loin. Je vois un exemple de code mauvais, un exemple de code bon, avec une explication de pour l'un est mauvais, pourquoi l'un est bon, et j'utilise ensuite le bon. Pas de biais cognitif. Si l'on est pas capable de saisir le message, c'est pas un biais cognitif, c'est une atrophie cérébrale à ce niveau là vu les exemples donnés par entwanne.

Le seul biais que je vois c'est que prendre les gens pour des débiles, cela tient à la prophétie auto-réalisatrice.

Bah va falloir que je trouve une source pour te convaincre. Ce que je n'ai pas sous la main, je n'ai que des exemples en tête (niveau école primaire et bac+1), ce qui ne fait pas une généralité.

Mais je t'invites à discuter pédagogie avec des enseignants si ça t'intéresse, pas besoin d'atrophie cérébrale pour se faire avoir.

Il me semble que cette recommandation, c'est si on te présente une technique que tu ne connais pas, en te disant c'est mauvais, puis une bonne technique que tu ne connais pas non plus. Là ton cerveau peut mélanger car il n'a pas encore bien intégré les deux façons de faire.

Ici c'est différent, c'est "ne faites pas comme ceci (que vous aviez l'habitude de faire), mais comme cela". Je pense aussi que ce serait contre-productif de ne pas donner le mauvais exemple. Parce que justement, si on ne me dit pas ce qu'il ne faut pas faire, je dirais "ok, j'utilise la bonne méthode, mais des fois je me permets de faire comme j'ai l'habitude (on m'a pas dit que c'était pas bien)"

Très bien, sa se rapprochera plus de ce que je te disais.