Le code que tu as mis dans ton commentaire ne peut pas faire ce que tu veux parce que tu fais ta boucle for sur une variable 'c', mais ensuite, dans la boucle, tu travailles avec la variable 'ligne'. En fonction du code du reste de ton script, soit tu as une erreur de syntaxe, soit la variable ligne est initialisée ailleurs, et tu obtiens un résultat, mais c'est pas du tout ce que tu veux.
Vu la taille des scripts que tu dois faire pour ces exos, c'est pas les quelques lignes d'import et d'ouverture de fichiers qui vont rendre tes commentaires illisibles, alors je te conseille de copier tes scripts complets en commentaire, ça nous évitera de devoir spéculer sur ce que tu fais ;)
Je te rappelle (ou t'indique) que tu peux utiliser des balises pour copier du code sur linuxfr, ça permet de préserver l'indentation et ça ajoute de la coloration syntaxique, c'est le Bien.
En python, sauf erreur de ma part, il n'est généralement pas recommandé d'écrire l'instruction sur la même ligne que le test. Si le if a une clause else, c'est même fortement déconseillé. Sur le plan cosmétique, ça devrait plus ressembler à:
parce que ça fait une recherche dans un index plutôt qu'un parcours de la liste de toutes les clefs, donc ça doit être plus performant, mais ce n'est pas une différence fondamentale.
Un truc un peu dommage pour les affectations de ce genre là, c'est qu'on va tester à chaque fois si la clef est présente avant d'incrémenter la valeur dans le dictionnaire, mais en fait, ce n'est utile que pour la première affectation de chaque clef. Du coup, à une époque, il n'était pas rare de voir des trucs comme ça:
C'est à dire qu'on incrémente directement la valeur dans le dictionnaire, et on traite l'exception quand la clef n'est pas présente (c'est à dire seulement la première fois qu'on incrémente chaque clef). Sur des petits volumes, le coût de traitement des exceptions est possiblement plus élevé que de tester à chaque éléments à traiter, mais sur des gros volumes, ça peut amener des gains de performances significatifs.
Mais il y a mieux ! Tu peux utiliser un defaultdict qui permet de définir une fonction à appeler quand on cherche à accéder à une clef absente du dictionnaire. Je ne met pas le code, parce que ça serait plus intéressant pour toi de l'écrire (et ça permet de découvrir lambda). Ci dessous, une session interactive pour illustrer un peu comment ça marche:
$ python3
Python 3.7.2 (default, Jan 32019, 02:55:40)[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license"for more information.
>>> from collections import defaultdict
>>> dd= defaultdict(lambda: 0)
>>> len(dd)# le dictionnaire est bien vide0
>>> dd[200]# mais quand on veut la valeur d'une clef absente, on n'a pas d'erreur0
>>> dd[200] +=1# on incrémente
>>> len(dd)# notre dictionnaire contient bien un couple (clef, valeur) maintenant1
>>> dd.items()# et c'est ce que l'on attendait
dict_items([(200, 1)])
[^] # Re: Mon code Question 2
Posté par gaaaaaAab . En réponse au message Exercices à résoudre en Python. Évalué à 4.
je me lance, dans la foulée de kaos.
Le code que tu as mis dans ton commentaire ne peut pas faire ce que tu veux parce que tu fais ta boucle for sur une variable 'c', mais ensuite, dans la boucle, tu travailles avec la variable 'ligne'. En fonction du code du reste de ton script, soit tu as une erreur de syntaxe, soit la variable ligne est initialisée ailleurs, et tu obtiens un résultat, mais c'est pas du tout ce que tu veux.
Vu la taille des scripts que tu dois faire pour ces exos, c'est pas les quelques lignes d'import et d'ouverture de fichiers qui vont rendre tes commentaires illisibles, alors je te conseille de copier tes scripts complets en commentaire, ça nous évitera de devoir spéculer sur ce que tu fais ;)
Je te rappelle (ou t'indique) que tu peux utiliser des balises pour copier du code sur linuxfr, ça permet de préserver l'indentation et ça ajoute de la coloration syntaxique, c'est le Bien.
Pour ces lignes là:
En python, sauf erreur de ma part, il n'est généralement pas recommandé d'écrire l'instruction sur la même ligne que le test. Si le if a une clause else, c'est même fortement déconseillé. Sur le plan cosmétique, ça devrait plus ressembler à:
J'aurais même plutôt écrit:
parce que ça fait une recherche dans un index plutôt qu'un parcours de la liste de toutes les clefs, donc ça doit être plus performant, mais ce n'est pas une différence fondamentale.
Un truc un peu dommage pour les affectations de ce genre là, c'est qu'on va tester à chaque fois si la clef est présente avant d'incrémenter la valeur dans le dictionnaire, mais en fait, ce n'est utile que pour la première affectation de chaque clef. Du coup, à une époque, il n'était pas rare de voir des trucs comme ça:
C'est à dire qu'on incrémente directement la valeur dans le dictionnaire, et on traite l'exception quand la clef n'est pas présente (c'est à dire seulement la première fois qu'on incrémente chaque clef). Sur des petits volumes, le coût de traitement des exceptions est possiblement plus élevé que de tester à chaque éléments à traiter, mais sur des gros volumes, ça peut amener des gains de performances significatifs.
Mais il y a mieux ! Tu peux utiliser un defaultdict qui permet de définir une fonction à appeler quand on cherche à accéder à une clef absente du dictionnaire. Je ne met pas le code, parce que ça serait plus intéressant pour toi de l'écrire (et ça permet de découvrir lambda). Ci dessous, une session interactive pour illustrer un peu comment ça marche: