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.
Très bien, sa se rapprochera plus de ce que je te disais.
La programmation c'est quelque chose d'itératif. On ne lit pas un bouquin pour finir par tout maîtriser avant de coder la première ligne. De facto, on code mal et on s'améliore (où il n'y aurait jamais au aucun développeur C++). Ne pas donner le mauvais code ne permet pas nécessairement d'identifier soi même la situation problématique et ne permet pas non plus de justifier d'un changement d'habitudes.
Il me semble que quand on lit un article sur les secrets d'un code pythonique c'est qu'on sait déjà faire un peu de python et que l'on veut améliorer ses façons de faire ; donc autant pour les identifier rapidement.
Je te conseille […] 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…).
Moi
Je n'ai pas dit de ne pas en parler du tout, j'ai dit de le présenter autrement et que le temps et la place accordé aux mauvais exemple doit être petite devant celle accordée aux bons. Ce qui n'est pas le cas actuellement dans les exemples. Pour l'instant, le mauvais code prend plus de place que le bon, et les commentaires sont éloignés des codes, ce qui peut in fine induire en erreur.
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
paraîtra bien plus compréhensible que
Je dirais que cela correspond plus à "demander pardon mais pas la permission"
"ask for forgiveness not permission"
Je suis donc en train de complètement retravailler la première section. J'avance bien mais il me reste quelques règles à expliquer/illustrer.
J'en ai profité pour faire quelques recherches et voir ce qui se faisait sur le sujet, j'ai été étonné de réaliser qu'il y avait très peu d'articles qui détaillaient le contenu de la PEP20.
Je devrais normalement être en mesure de publier en beta une nouvelle version de l'article dans la semaine à venir.
Bonjour les agrumes !
La bêta a été mise à jour et décante sa pulpe à l'adresse suivante :
Merci d'avance pour vos commentaires.
Diff:
J'ai déjà rencontré quelques problèmes de mise en forme (italique, lien), que je corrigerai pour la prochaine version.
Bonjour les agrumes !
La bêta a été mise à jour et décante sa pulpe à l'adresse suivante :
Merci d'avance pour vos commentaires.
Diff :
C'est bien mieux. Très intéressant !
Peut-être n'est tu pas obligé d'être si régulier dans l'énoncé des principes : si deux principes vont bien ensemble regroupe les.
M'enfin rien de bien grave, après une correction d'orthographe (si ya besoin) ça peut être OK 
Bonjour les agrumes !
La bêta a été mise à jour et décante sa pulpe à l'adresse suivante :
Merci d'avance pour vos commentaires.
Diff :
Pour le premier code, ne serait-il pas plus lisible d'écrire:
1 | if number > 0 and number not in invalid_numbers: |
Sinon pour quelque chose de très laid mais qui fonctionne: 
1 | if 0 < number not in invalid_numbers: |
Pour le premier code, ne serait-il pas plus lisible d'écrire:
Si, et c'est ce que je voulais écrire, mais je me suis emmêlé.
Bonjour les agrumes !
La bêta a été mise à jour et décante sa pulpe à l'adresse suivante :
Merci d'avance pour vos commentaires.
Salut, ton tutoriel ne parle pas du Duck Typing qui semble être un principe contraire à une règle de la PEP20 "Le plat est préférable à l'imbriqué".
Quelle est la différence ? Serait-il pertinent d'en parler ?
Je parle vaguement du duck-typing lors du principe KISS. Mais je ne vois pas en quoi il est contraire à la règle que tu énonces, tu pourrais expliciter ? C'est d'ailleurs un exemple à base de duck-typing que je propose en illustration de cette règle.
Sinon, pour remettre dans le contexte, cet article était à la base prévu pour être compris dans un cours plus large sur la programmation orientée objet en Python. Donc le duck-typing y est exposé et explicité.
Dans cet article, j'ai préféré l'indiquer comme simple rappel (et 'utiliser dans les exemples), que de réitérer un cours dessus.
Autant pour moi, c'était une incompréhension de ma part (rien à voir avec ton tutoriel).
J'ai tout mélangé 
Bonjour les agrumes !
La bêta a été mise à jour et décante sa pulpe à l'adresse suivante :
Merci d'avance pour vos commentaires.
Un article très intéressant. J'ai peu de retour à faire :
(Although that way may not be obvious at first unless you're Dutch) La manière évidente est la manière la plus idiomatique.
Pas pour le public cible de cet article, puisque justement la manière évidente ne l'est pas au premier abord.
Ce principe s'oppose au LBYL (Look before you leap, Regarde avant d'essayer)
Tu fais dans toute la partie version longue (acronyme court) sauf pour cette phrase. (je sais, il n'y a que moi pour remarquer ça spontanément 
)
Ça manque de lien. Quand tu parles de classmethod par exemple, un lien vers la doc serait intéressant.
C'est tout, pas d'autre remarque, si ce n'est que c'est un bon article.
Pas pour le public cible de cet article, puisque justement la manière évidente ne l'est pas au premier abord.
Je n'ai pas compris cette remarque.
Tu fais dans toute la partie version longue (acronyme court) sauf pour cette phrase. (je sais, il n'y a que moi pour remarquer ça spontanément
Oui mais c'est fait volontairement. Les autres acronymes utilisés sont des principes que je détaille, je préfère alors commencer par en donner le nom complet.
Alors que LBYL n'est que cité, c'était une manière de lui donner moins d'importance.
Ça manque de lien. Quand tu parles de
classmethodpar exemple, un lien vers la doc serait intéressant.
Je vais y réfléchir.
C'est tout, pas d'autre remarque, si ce n'est que c'est un bon article.
Merci pour ton retour 
Il devrait y avoir une – et de préférence une seule – manière évidente de le faire. Donc La manière évidente est la manière la plus idiomatique. Mais Bien que cette manière ne vous semble pas évidente au premier abord.
Tu mets le commentaire La manière évidente est la manière la plus idiomatique dans la partie qui dit que justement, cette évidence n'est pas innée.
Tu mets le commentaire La manière évidente est la manière la plus idiomatique dans la partie qui dit que justement, cette évidence n'est pas innée.
Oui mais la manière idiomatique n'est pas non plus innée. La manière évidente (qui est la manière idiomatique) vient avec la pratique du langage.
Bonjour,
La bêta du contenu « Les secrets d'un code pythonique » a été désactivée.
Bonjour,
La bêta du contenu « Les secrets d'un code pythonique » a été désactivée.
