bonjour,
j'ai une liste donné
a=[['4'], ['5'], ['3', '1', '25'], ['1', '0', '12'], ['2', '0', '-5'], ['0', '1', '0'], ['2', '1', '7'], []] et je voudrais changer les elements de cette liste qui sont de types str en int comment je doit m'y prendre?
d'abord, c'est une liste de listes...
sauf que là, j'ai créé une nouvelle liste de liste et non pas remplacé les éléments dans la liste...Code:[[int(y) for y in x] for x in a]
pour remplacer les éléments dans chaque sous-liste, il faut parcourir chaque sous-liste de la liste avec un index...
et je ne donnerai pas de suite la réponse...
Jusqu'ici tout va bien...
Ou :
Code:map(lambda x: map(int, x), a)
bonsoir,j'ai pu faire comme ça
Code:raw=[['3', '1', '25'], ['1', '0', '12'], ['2', '0', '-5'], ['0', '1', '0'], ['2', '1', '7'], []] b=[list(map(int, elem)) for elem in raw]
Dans le cas présent utiliser uniquement des list-compréhension ou map est plus clair et maintenable que de les mélanger.
arghhhh
en python2 les listes sont 20 à 30 fois plus performantes que les map mais en python3, c'est les map qui sont 10 fois plus performantes...
sauf que map en python3 renvoie des objets map, pas des listes... et ça marche moins bien dans un json.dumps(...)
pour avoir de vraies listes, il faut list(map(lambda x: list(map(int, x)), a))
et du coup, list(map(lambda x: list(map(int, x)), a)) est un poil plus lent que [[int(y) for y in x] for x in a]
( python3 est nettement plus lent (20 fois) que python2 pour [[int(y) for y in x] for x in a] ... un peu dommage, quand même...)
mais globalement on a toujours créé une nouvelle liste, ce qui peut ne pas marcher s'il fallait absolument modifier la liste initiale (genre liste passée en paramètre, mais pas de return de nouvelle liste).
Jusqu'ici tout va bien...
1) il faut vraiment être motivé pour faire du python 2 de nos jours vu qu'il a été arrêté au 1er janvier et que les auteurs du langage recommendent de passer en python3 aussi vite que possible (https://www.python.org/doc/sunset-python-2/)Envoyé par polo974
2) je veux bien une référence parce que coté différence de perfs, on lit plutôt que les 2 sont proches : Voir https://stackoverflow.com/questions/...ehension-vs-ma
https://blog.finxter.com/which-is-fa...ion-in-python/
De mon coté, je trouve un facteur 2 en faveur de la list-compréhension et dans le même sens entre python2 et python3
Et cela permet la lazy évaluation, de s'initier à la programmation fonctionnelle, d'être dans les logiques map/reduce, etc. Les 2 usages se discutent parce que d'un autre coté, les liste-compréhensions sont plus fréquentes en python et plus faciles à comprendre pour les débutants.
Là aussi, je veux bien une référence : je trouve des temps très proches.
Oui parce que c'est une bien meilleure idée et que cela évite de nombreux bugs.
Je sais, je suis d'ailleurs sur un gros chantier de basculement de code (écrit par beaucoup, dont une partie assez ... comment dire ... (une sorte de mykado fait avec des grenades dégoupillées...).
Je demandais de basculer en douceur depuis un paquet d'années, mais "Ce n'est pas l'urgence...".
Et maintenant, je déguste et hérite de leurs "choses" et comme la perf est souvent un soucis, je fais pas mal de comparaisons afin d'améliorer (ou ne pas trop perdre), d'où ce réflexe...En fait, j'ai bugué (la honte...) en py2 (les variables dans la list-compréhension ne sont pas locales en py2 alors qu'elles le sont en py3... (mais de toute façon, c'est pas bien comme j'avais bâclé mon test en réutilisant des noms sur une lettre (et bam, une leçon pour moi2) je veux bien une référence parce que coté différence de perfs, on lit plutôt que les 2 sont proches ...
De mon coté, je trouve un facteur 2 en faveur de la list-compréhension et dans le même sens entre python2 et python3))).
Après nouveaux tests, en gros, c'est légèrement en faveur de la list-comprehension, et légèrement en faveur de py3.
Oui, les liste-compréhensions sont "immédiates", alors que les map (et autres générateurs) sont en devenir.
Et cela permet la lazy évaluation, de s'initier à la programmation fonctionnelle, d'être dans les logiques map/reduce, etc. Les 2 usages se discutent parce que d'un autre coté, les liste-compréhensions sont plus fréquentes en python et plus faciles à comprendre pour les débutants.
Chacun ses avantages et ses inconvénients et donc domaine d'utilisation.
L’intérêt des générateurs est lorsqu’on manipule de très grosses quantités de données: on n'explose pas la ram, par contre:C'est (à mon avis) nettement plus subtil que les pointeurs en C dont beaucoup font tout un plat
- ce sont des objets "one shot", on ne les parcourt qu'une seule fois...
- ce sont des objets "en devenir", si on modifie la source après la création du map (oui, je sais, c'est pas bien...), le résultat du parcourt du map en est affecté.
Ah, et puisque j'ai parlé de générateur: voici le générateur sans passer par map:
il suffit juste de remplacer les [] par des ()... (ici 2 fois, vu qu'on a des listes imbriquées) et hop, on a un objet "en devenir"...g = ((int(y) for y in x) for x in a)
(à propos de nouvelle liste vs modifier la liste originelle):
C'est sûr, mais la demande était ce qu'elle était (et peut-être mal formulée).Oui parce que c'est une bien meilleure idée et que cela évite de nombreux bugs.
Jusqu'ici tout va bien...
