Parce que une fois sur deux le maximum apparait 2 fois par ligne. On doit effectivement pouvoir s'en tirer en utilisant la symétrie mais jusqu'à preuve du contraire l'algorithme se complexifie et vu que le but est plus ou moins de faire dans la simplicité on ne s'encombre pas avec ça. Après si l'on recherche la performance, je ne suis pas certain que la récursion soit la solution (on est limité par la taille de la pile d'appel). Sinon, je t'invite à proposer une solution utilisant la symétrie
Edit: Idem, pas lu la deuxième page en entier. Mais ça répond à la question
Inkamath on GitHub - Interpréteur d'expressions mathématiques. Reprise du développement en cours.
pourquoi vous calculer de fois la meme valeur, la premiere pour la case i et une deuxieme fois pour nombre_case-i sachant que c'est symetrique?
Une solution utilisant la symétrie a été proposée.
Je trouve le gain minime compte tenu que
-- ça complique la réflexion pour produire le code
-- ça donne un code moins lisible (enfin, c'est mon avis et il ne fait pas l'unanimité).
Or, toujours selon moi, l'avantage de Python est qu'il permet de coder simplement et facilement. Donc chaque fois que ce n'est pas pénalisant, et hors d'un contexte particulier (funnytude par ex) je priviligierai la simplicité et la facilité à l'astuce. Maintenant, chacun est libre.
Je pense qu'on ne code pas les mêmes choses suivant qu'on apprend Python que si on apprend le C. Je trouve que Python, par son haut niveau porte plus à coder des choses intéressantes ou amusantes, et C, par ses limitations (dues au bas niveau du langage) et sa discipline, incitent à coder des choses peu intéressantes, voire triviales (coder le max d'une liste ou le calcul du nombre de caractères d'une chaîne, c'est pas super exitant mais c'est incontournable en C).
Voici ma version(je ne garde que les deux dernieres lignes en memoire, celles qui m'interressent)
def pascal(n):
if n == 1: return 1
new = [] # ligne en cours
old = [1, 1] # ligne precedente
for i in range(2, n+1):
new = [1] + [old[j] + old[j-1] for j in range(1, i)] + [1]
old = new
return new[n/2]
et la version "avec symetrie":
def pascal(n):
if n == 1: return 1
new = []
old = [1, 1]
for i in range(2, n+1):
new = [1] + [old[j] + old[j-1] for j in range(1, i/2 + 1)]
if i % 2 == 0:
new += reversed(new[:i/2])
else:
new += reversed(new[:i/2+1])
old = new
return new[n/2]
Mais c'est vrai que la dewuxieme version est complique pour pas grand chose
Ça me convient très bien, les listes en compréhension sont très lisibles et très naturelles. Je ne les ai pas utilisées dans mon code car ... je n'y ai pas pensé bon et surtout que j'ai voulu donner le tour le plus élémentaire à mon code alors qu'en pratique il me semble qu'on apprend les listes en compréhension après les boucles.
Juste un truc, je trouve tes noms de variables trop longs, ils t'obligent à aller à la ligne ce qui est moins facile à suivre que sur une seule ligne. Tu pouvais utiliser comme nom par exemple old et new.
Personnellement, je pense que ce serait plus clair en remplaçant n par n_max, i par n et j par k ou p, pour retrouver des variables qui font directement penser aux notations utilisées dans le triangle de Pascal.
Pour le coup, c'est moi qui ai plus de mal à lire ta version. C'est très subjectif en effet.
Tout à fait, à chacun d'apprécier selon ses goûts et son niveau.
En parlant de ça, c'est vrai que l'algorithme employé n'est pas très explicite.
Pour corriger ça, j'ai rajouté un petit affichage du tableau à chaque itération, de manière à ce que l'on comprenne bien comment la valeur est obtenue.
def pascal(n):
tab = [0 for _ in range(0,n//2)] + [1] # Tableau de longueur n/2+1
print(tab)
for _ in range(n): # Calcul de la demi-ligne d'indice n
for i in range(n//2):
tab[i] += tab[i+1]
print(tab)
return tab[0] # Résultat : dernière valeur
Et voilà l'exécution.
(J'ai pris la liberté de rajouter des espaces manuellement ci-dessous pour que ce soit plus lisible).
Comme on le voit, on ne construit que la "dernière demi-ligne de droite" du tableau.
Citation : candide
Citation : NoHaR
OK, je poste l'explication.
(...)
Voilà.
Oui mais ce n'est pas du tout ce genre d'explication que j'attendais. As-tu testé ton code ?
Oups ! effectivement, il n'affiche pas tout à fait ce que l'on attend de lui.
Je corrige.
EDIT :
Voilà :
>>> pas = lambda n,p=None: 1 if p == 0 or p == n or n==0 else pas(n-1,p-1) + pas(n-1,p) if p else pas(n,n//2)
>>> for k in range(20): print(pas(k))
...
1
1
2
3
6
10
20
35
70
126
252
462
924
1716
3432
6435
12870
24310
48620
92378
J'ai déjà dit plus haut que les solutions récursives étaient propres à faire exploser la pile en Python (et d'une manière générale, à éviter):
Ce one-liner est rigolo quand il s'agit de calculer des valeurs assez basses, mais son exécution est extrêmement lente, d'une part (c'est sensible déjà quand on arrive vers pas(20), pas(25)...), et d'autre part, risque d'exploser littéralement la pile d'appel et de faire planter python (dans le cas de ce programme, c'en est presque un "fork bomb": chaque pas en avant dans la récursivité multiplie le nombre d'appels sur la pile par 3). Pour des valeurs pas trop grandes (à vue de nez jusqu'à 15), en revanche, il affiche des performances pas trop dégueulasses puisque, "par chance", le tableau de pascal est un "triangle", et donc que l'on arrive assez rapidement à la condition d'arrêt dans les embranchements "externes droite" (c'est-à-dire les appels successifs à bin(n-1,p)).
J'ai déjà dit plus haut que les solutions récursives étaient propres à faire exploser la pile en Python
Non, ce n'est pas la cause du problème, tu aurais le même problème en C avec une pile supportant des centaines de milliers d'appels. Nouvelle preuve que le concept de la récursivité est difficile à manipuler.
J'ai déjà dit plus haut que les solutions récursives étaient propres à faire exploser la pile en Python
Non, ce n'est pas la cause du problème, tu aurais le même problème en C avec une pile supportant des centaines de milliers d'appels. Nouvelle preuve que le concept de la récursivité est difficile à manipuler.
Non d'accord, il y a aussi le problème de la complexité: ici la solution récursive est d'une complexité exponentielle en O(2^n) (et ça, sailemal !), alors que la solution itérative que j'ai proposé juste avant est polynomiale, en O(n²/2), ce qui est beaucoup mieux, sans toutefois être génial.
Non d'accord, il y a aussi le problème de la complexité: ici la solution récursive est d'une complexité exponentielle
Bien sûr. Et c'est cette remarque qui aurait dû accompagner ton code car il est quand même très surprenant qu'il ne soit pas capable de calculer la plus grande valeur de la ligne 40 du tableau de Pascal alors que la solution itérative va le faire en quelques millisecondes.
nNon d'accord, il y a aussi le problème de la complexité: ici la solution récursive est d'une complexité exponentielle en O(2^n) (et ça, sailemal !), alors que la solution itérative que j'ai proposé juste avant est polynomiale, en O(n²/2), ce qui est beaucoup mieux, sans toutefois être génial.
Je n'y comprends rien à la récursivité:
-1) Pourquoi l'utiliser, qu'elle en est l'utilité ?
-2) Pourquoi parle t'on de: O(n²/2) ou O(2^n) ?
-3) En à t'on vraiment besoin ? (des formules)
-4) Qu'elle est la différence entre les deux ?
-5) Existe t'il d'autre forumules ?
Je suis perdu, j'aurais besoin de quelque explications s'il vous plaît. Je tiens à vous rappeller que je suis nul en maths (Donc allez y doucement)
-1) Pourquoi l'utiliser, qu'elle en est l'utilité ?
La récursivité est une approche qui sert à résoudre certains problèmes lorsque l'on utilise un langage pensé pour ça (OCamL est un bon exemple), ou que l'on ne peut (ou sait pas) encore faire autrement.
Pour certains problèmes comme celui des tours de Hanoï, il est plus facile de trouver une solution récursive.
Citation : realmagma
-2) Pourquoi parle t'on de: O(n²/2) ou O(2^n) ?
C'est la complexité de l'algorithme. En gros, c'est un ordre de grandeur du nombre d'opérations que le programme va effectuer s'il doit traiter une donnée de taille n, c'est donc un indicateur de sa rapidité.
Citation : realmagma
-3) En à t'on vraiment besoin ? (des formules)
Dans l'absolu, oui, puisque ça permet de savoir si le programme va terminer en quelques millisecondes ou en 3 fois l'âge de l'univers. Il est bon d'en avoir une notion.
Citation : realmagma
-4) Qu'elle est la différence entre les deux ?
La fonction qui à x associe <math>\(f(x) = 2^x\)</math> croit beaucoup plus rapidement que la fonction qui à x associe <math>\(f(x) = x^2\)</math>, donc un algorithme de complexité "en O(2^n)" va mettre très longtemps à terminer son travail si on fait grossir la donnée que l'on lui passe, alors qu'un algo de complexité "en O(n^2)" mettra moins longtemps (quoi qu'il sera toujours long pour de grandes valeurs de n).
Oui, mais personnellement en tout cas, j'ai très rarement besoin d'utiliser ce genre de truc en Python. C'est certainement le cas des projets que tu cites aussi.
Citation
En effet, je comprends que ça puisse étonner. Mais un nom plus long heurte ma façon de penser
Mmmh ? Le problème du choix des noms de variable est plus compliqué que ça. Déjà, "ligne" et "colonne" sont des noms courts (quand on parle de variable au nom court, c'est pour éviter les numero_de_la_ligne_qu_on_est_en_train_de_visiter_pour_le_calcul, pas pour tomber dans l'extrême "3 lettres, pas plus").
Ensuite, l'intérêt de choisir des variables courtes, c'est pour faciliter la lecture, pour soi et pour les autres. On ne cherche pas spécialement à faciliter l'écriture du code, sinon un i ou un j suffirait. Cette lecture doit être facilitée pour soi et pour les autres : si ligne ou colonne peuvent heurter ta façon de penser, c'est au moement d'écrire le code. Quand tu le reliras, tu comprendras tout de suite et ça ne te dérangera certainement pas beaucoup.
Par contre, pour quelqu'un qui n'a pas ton code en mémoire, il a d'abord besoin de savoir ce que ces variables représentent. Dans ce cas encore, des noms explicites sont un meilleur choix.
Pour la récursivité il faut simplement penser que certains problèmes sont très bien penser avec la récursivité et d'autre avec une itération.
Même si cela parait barbare et dur, on en fait sans s'en rendre compte.
Par exemple la fonction factorielle est le produit des entiers de 1 à n.
Donc fact(n) = n * (n - 1) * (n - 2) ... * 1
Or on raisonne aussi en disant que fact(n) = n * fact(n - 1)
Certains raisonnement sont plus simples à faire avec la récursivité et d'autre non.
Pour les O(n^2/2) et O(2^n) c'est la complexité de l'algorithme. Grace à ces formules on peut évaluer facilement le nombre d'opération qu'amène à faire l'algorithme.
Comme n^2/2 croit moins rapidement que 2^n (pour 10 par exemple : 10^2/2 = 50 alors 2^10 = 1024) alors il est plus approprié de choisir l'algo de complexité O(n^2/2)
Pour les autres formules en gros, il y a les algorithmes à complexités linéaire : O(n), logarithme : O(ln n), exponentiel : O(a^n), polynomiale : O(n^a).
Je suis "chiant" désolé, mais comment sait on quel formule on utilise pour un quelconque algo.
L'algo factoriel utilise lequel ?
Merci pour le lien Candide, je l'avais déjà lu il y a quelques mois, bien entendu tout cela était du "charabia" pour moi. En le relisant tout à l'heure, j'ai compris quelque notions utiles. (Pourquoi je fais un blocage sur les maths moi ?)
Déjà, "ligne" et "colonne" sont des noms courts (quand on parle de variable au nom court,
Courts ? certainement pas car alors comment qualifierait-t-on des variables ayant un nom 7 fois moins long, ce qui est très courant comme i, j, k, n, p, x, etc.
Le choix que j'ai fait est parfaitement légitime, tu essayes de me le contester sans donner le moindre argument autre que ta propre subjectivité à laquelle tu essayes de me ramener. Alors je vais te donner des éléments objectifs : fais un petit tour dans du code Python respecté (matplotlib, Cpython, PyQt, etc), et tu verras sans cesse des
-- for val (et non for value ou for values)
-- le très très fréquent for col (et non for column ni for colonne ni for columns ni for colonnes),
-- for arg (et non for arguments ou for argument)
-- for var (et non for variable ou for variables)
Citation : Maxibolt
Ensuite, l'intérêt de choisir des variables courtes, c'est pour faciliter la lecture, pour soi et pour les autres. On ne cherche pas spécialement à faciliter l'écriture du code, sinon un i ou un j suffirait. Cette lecture doit être facilitée pour soi et pour les autres : si ligne ou colonne peuvent heurter ta façon de penser, c'est au moement d'écrire le code. Quand tu le reliras, tu comprendras tout de suite et ça ne te dérangera certainement pas beaucoup.
Une fois de plus, tu essayes de m'enfermer dans ta subjectivité. Si tu veux utiliser for colonnes, je ne t'en empêche pas, moi je trouve plus lisible for col et il n'y a rien d'illégitime à le faire , c'est monnaie courante.
Citation : Maxibolt
Par contre, pour quelqu'un qui n'a pas ton code en mémoire, il a d'abord besoin de savoir ce que ces variables représentent. Dans ce cas encore, des noms explicites sont un meilleur choix.
A nouveau, ils ne sont pas objectivement meilleurs. S'il fallait faire comme tu dis, on aurait jamais d'abréviations, on aurait que des noms complets, c'est impossible dans du code. Quand on voit lig et col, et qu'on a affaire à un tableau (tableau de Pascal), on comprend tout de suite (si on a un peu d'expérience de lecture de code source) que lig et col représentent des LIGnes et des COLonnes. De la même façon que si tu vois lun mar mer etc, tu vas comprendre que lun veut dirre lun. Autrement dit on ne comprend pas les identificateurs intrinsèquement mais en fonction d'un contexte.
On lieu de vouloir m'imposer tes visions, tu ferais bien de te procurer The practice of Programming dont un des auteurs n'est autre que Kernighan. On y lit par exemple que Local variables used in a conventional ways can have very short names. Pour ajouter, tiens, tiens, ceci :
Programmers are often, encouraged to use long variable names regardless on context. This is a mistake : clarity is often achieves through brevity.
En Python, il est vrai que l'on préfère conventionnellement (PEP-8 oblige) que les variables portent un nom explicite. A ce propos, je ne vois pas de mal à mettre des noms de variables à 7, 8, 10 caractères.
Cependant, l'usage, dans pas mal de cas précis (les indices boucles, ou des coordonnées) de noms de variables du style "i,j,k,x,y,z" est parfaitement explicite, tout comme, dans une matrice, on aime bien écrire "col" au lieu de "column", de manière à avoir un pendant équilibré dans l'aspect général du code aux trois caractères de "row".
Ce qui est abusif, c'est, d'une part les "bdd_query_search_result", et les "a = complicated_function(with, lots, of, args)". Il s'agit de trouver un pendant entre l'explicite (qui permet de garder un code facilement compréhensible) et le concis ("for it in items:")
Je m'en réfère donc à pylint, qui m'engueule chaque fois que mes variables internes ne font pas plus de 3 caractères, mais pour qui je force les noms 'x, y, z, i, j' comme étant acceptables dans un contexte précis.
Dans certains cas, oui, les variables très courtes sont préférables. Au passage, l'argument de Candide pour dire que "ligne" n'est pas un long court est bidon : dans ce cas, col ne l'est pas non plus puisqu'on pourrait écrire c.
Maintenant, col est par exemple beaucoup plus utilisé que lig. Quand on voit col tout seul, on pense plus facilement à une colonne (entre autres à cause du fait que les anglais l'utilisent, par exemple) qu'on ne pense à une ligne en voyant lig. De même, si je te dis "lun", tu ne penseras pas directement à lundi, il faut que tu précises "mar mer jeu" pour que le lien se fasse.
Un nom de variable dont la compréhension immédiate nécessite d'autres noms de variables dans le code est objectivement mal choisi. Surtout dans un code si court, où "ligne" et "colonne" n'auraient posé aucun problème (ou row et col éventuellement).
Et, au risque de me répéter : tu pars du principe que "colonne" et "ligne" sont des noms de variable longs. C'est objectivement ridicule. Je n'ai pas dit qu'il fallait des noms très détaillés, mais "ligne" est plus clair que "lig" (c'est objectivement vrai, la preuve : je n'ai pas compris tout de suite, alors que tout le monde comprend tout de suite avec ligne) et ne rajoute que deux caractères. Vouloir abréger ses noms de variable, ok, mais dire "celui là est trop long, il a deux lettres de plus et rajoute 6 caractères à mon code" relève de l'extrémisme le plus primaire, surtout quand on "comprend que ça puisse étonner" et quand le nom "long" est objectivement plus clair.
Appliquer des conseils, c'est bien, les comprendre et les appliquer correctement, c'est mieux.
Au passage, l'argument de Candide pour dire que "ligne" n'est pas un long court est bidon : dans ce cas, col ne l'est pas non plus puisqu'on pourrait écrire c.
Certainement pas, de c je ne vais pas déduire col, ou beaucoup moins facilement, c étant bien plus polysémique que col. Sans compter que par homogénéité (be consistent disent kernighan and Pike, tu vas y avoir droit assez régulièrement), si j'écris c pour col, je dois écrire l pour lig et il est bien connu que un l minuscule est une lettre à proscrire dans du code source à cause des confusions avec 1 (un) et le trait vertical |).
Citation : Maxibolt
Maintenant, col est par exemple beaucoup plus utilisé que lig.
Parce qu'en anglais, comme row a aussi 3 lettres, on a rien à modifier.
Citation : Maxibolt
De même, si je te dis "lun", tu ne penseras pas directement à lundi, il faut que tu précises "mar mer jeu" pour que le lien se fasse.
Et bien justement, c'est exactement le même cas ici : tu as lig et à la ligne suivante tu as col. De même, tu pourrais avoir dim et ne pas comprendre puis comprendre car à la ligne suivante tu auras lun.
Citation : Maxibolt
tu pars du principe que "colonne" et "ligne" sont des noms de variable longs. C'est objectivement ridicule. Je n'ai pas dit qu'il fallait des noms très détaillés, mais "ligne" est plus clair que "lig" (c'est objectivement vrai, la preuve : je n'ai pas compris tout de suite, alors que tout le monde comprend tout de suite avec ligne) et ne rajoute que deux caractères. Vouloir abréger ses noms de variable, ok, mais dire "celui là est trop long, il a deux lettres de plus et rajoute 6 caractères à mon code" relève de l'extrémisme le plus primaire, surtout quand on "comprend que ça puisse étonner" et quand le nom "long" est objectivement plus clair.
Appliquer des conseils, c'est bien, les comprendre et les appliquer correctement, c'est mieux.
Citation : Maxibolt
tu pars du principe que "colonne" et "ligne" sont des noms de variable longs.
Pure invention de ta part. Je dis que je trouve que dans le contexte présent, c'est trop long (pour moi), non pas objectivement mais très subjectivement. Et que beaucoup de programmeurs C ou Python font exactement pareil, cf. les exemples que je t'ai donnés ci-dessus.
Citation : Maxibolt
(ou row et col éventuellement).
ne rajoute que deux caractères.
Sauf qu'il y a un principe que j'applique : be consistent. Donc, si j'écris ligne je dois écrire colonne et donc je passe de trois caractères parlant à 7 caractères, ce que je ne veux pas.
Citation : Maxibolt
relève de l'extrémisme le plus primaire,
Tu crois pas que t'y vas un peu loin là ??? Tu perds toute mesure. Je cesse cette discussion.
Certainement pas, de c je ne vais pas déduire col, ou beaucoup moins facilement, c étant bien plus polysémique que col. Sans compter que par homogénéité (be consistent disent kernighan and Pike, tu vas y avoir droit assez régulièrement), si j'écris c pour col, je dois écrire l pour lig et il est bien connu que un l minuscule est une lettre à proscrire dans du code source à cause des confusions avec 1 (un) et le trait vertical |).
De lig, je n'ai pas déduit immédiatement ligne, preuve que le nom est mal choisi, puisqu'un bon nom de variable doit être immédiatement compris par les lecteurs de ton code.
Au passage, les arguments d'autorité n'ont aucune valeur, bien qu'ils semblent être tes préférés.
Citation
Parce qu'en anglais, comme row a aussi 3 lettres, on a rien à modifier.
Exactement. Mais je ne vois pas ce que ça change au problème.
Citation
Et bien justement, c'est exactement le même cas ici : tu as lig et à la ligne suivante tu as col. De même, tu pourrais avoir dim et ne pas comprendre puis comprendre car à la ligne suivante tu auras lun.
Oui, et "dim" serait un très mauvais choix pour "dimanche" (en voyant dim, je pense dimension. En voyant le lun derrière, je n'aurais pas compris sans un certain effort de devinette, ce que des noms clairs, que tu n'aimes pas utiliser, m'auraient permis d'éviter, comme il est de bon ton de faire).
Ici, pareil, tes lecteurs ne devraient pas avoir besoin de lire les lignes suivantes pour comprendre ce qu'est ta variable.
Citation
Pure invention de ta part. Je dis que je trouve que dans le contexte présent, c'est trop long (pour moi), non pas objectivement mais très subjectivement. Et que beaucoup de programmeurs C ou Python font exactement pareil, cf. les exemples que je t'ai donnés ci-dessus.
Oui, beaucoup de programmeurs écrivent aussi des choses comme :
x += 1 #on incrémente x de 1
Donc de un, argument d'autorité, de deux, argument stupide : c'est pas parce que beaucoup de gens le font que c'est une bonne pratique. Et entre "je trouve que c'est trop long" et "je pars du principe que c'est trop long", il n'y a qu'une différence : le nombre de mots de la phrase.
Citation
Sauf qu'il y a un principe que j'applique : be consistent. Donc, si j'écris ligne je dois écrire colonne et donc je passe de trois caractères parlant à 7 caractères, ce que je ne veux pas.
C'est justement le problème. Refuser d'écrire des noms clairs pour gagner 4 caractères relève de l'extrémisme, par définition même. D'un extrémisme ridicule, et encore plus dans ton code d'exemple où tu n'avais aucune problème de place (pour faire des lignes de 79 caractères par exemple).
Citation
Tu crois pas que t'y vas un peu loin là ??? Tu perds toute mesure. Je cesse cette discussion.
Non, je n'y vais pas trop loin. Mais belle pirouette pour terminer une discussion qui te dérange.
De toute façon Candide à toujours raison, c'est une forme d'extrémisme aussi
Laisse tomber Maxibolt c'est une discussion qui ne mènera à rien compte tenu que Candide ne changera pas sa façon de coder (bonne ou mauvaise) et sa façon de penser (qui est bien pire d'ailleurs).
En tout cas moi qui ne suis pas informaticien à la base, il est évident que je préfère ligne à lig et colonne à col pour ma compréhension, mais étant dans l'exercice, j'avoue que j'avais compris ce qu'il voulait dire.
J'ai fini par le comprendre aussi... Après avoir lu qu'il y avait un "col", et fait le rapprochement. C'est justement ce qui me fait dire que le nom était mal choisi, puisqu'uniquement pour éviter de taper 4 caractères de plus, il a compliqué la compréhension de son code.
T'es intelligent mais faut t'expliquer longtemps ...
En attendant, j'ai remarqué un truc avec toi, à la différence de moi-même, fred1599, NoHaR, GurneyH, EMC1, rz0, -ed- quand il était là, et tant d'autres : tu ne postes jamais de code complet, juste une un tout petit petit échantillon par-ci, un échantillon par-là, et encore c'est très rare. Pour moi, ça fait une grosse différence. Facile dans ces condtions de venir gloser quand on ne produit rien : tu ne prends aucun risque.
Effectivement, mon temps de codage en Python était plutôt occupé ces temps-ci par un système de reconnaissance de visages via une webcam. Maintenant qu'il est terminé, je vais pouvoir écrire plus de choses (et puis bon, sur ce sujet, que dire de plus que ce qui a déjà été dit ?).
Mais ne confond pas "ne produit rien" et "je ne vois aucune production".
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
entwanne — @entwanne — Un zeste de Python — La POO en Python — Notions de Python avancées — Les secrets d'un code pythonique