Bug de mémoire ou une logique qui m'échappe ?

Bonjour,
J'ai un problème avec les listes python :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

liste = list([]) #Je crée une liste liste.append(7854) #J'y met des valeurs au pif liste.append(4546) #J'y met des valeurs au pif liste.append(8514) #J'y met des valeurs au pif   save = liste #Je crée une copie de la liste pour la manipuler sans modifier la liste de départ   del save[0] #Je modifie la liste crash-test   print(liste) #J'affiche l'ancienne liste pour vérifier si elle n'a pas changer #Resultat: liste = [[4546],[8514]]   #ELLE A CHANGER !!!

---

Je ne comprend pas !
Par exemple sans liste ça ne fait pas ça :

Code:

---

1 2 3 4 5 6 7

a = 0 b = a b += 1   print(a) #Resultat : a = 0 (Et non 1 !)

---

Merci de votre aide
Désolé la langue française que je maltraite... :)

Code:

---

save = liste.copy()

---

Il faut copier le contenu comme ci-dessus sinon save et liste sont "liées"...

Citation:

---

Envoyé par LeNarvalo

Code:

---

save = liste.copy()

---

Il faut copier le contenu comme ci-dessus sinon save et liste sont "liées"...

---

Un grand merci !

C'est quand même bizarre tout ça...

Il existe des objects muttables et des objects immutables, un object muttable est souvent un object / type de donnée (suivant les langages où un tableau ne serait qu'une suite de pointeur) où l'on pourra faire quelque chose sans devoir le recréer entièrement.
Un object immutable est un object dont on ne peux pas changer la valeur, on doit créer un nouvel object en mémoire.

les variables ne sont que des étiquettes qui pointent sur des zones mémoires (d'où la notion de pointeur)

quand vous faites a = 0; b=a; b+=1 voici ce qu'il se passe dans l'ordinateur (dans le cas général d'un langage quelconque ne procédant à aucune optimisation):

je crée une zone mémoire où j'y met la valeur 0, cette zone mémoire à l'adresse 0xABCD1
je dis que a pointe vers 0xABCD1

Je regarde vers quoi pointe a
je lis la valeur de la zone mémoire 0xABCD1qui vaut 0
je crée une nouvelle valeur 0 dans la mémoire, elle a l'adresse 0xABCD2
je dis que b pointe vers 0xABCD2

Je regarde vers quoi pointe b
je lis la valeur de la zone mémoire 0xABCD2 qui vaut 0
je calcule 0+1
je crée une nouvelle la valeur calculé dans la mémoire, elle a l'adresse 0xABCD3
je dis que b pointe vers 0xABCD3

Mais les langages sont intelligents, ils optimisent:
ils vont faire pointer a et b vers la même zone mémoire sans même regarder la valeur
ils ont un garbage collector, en gros ils vont désallouer les zones mémoires inutilisés (dans le cas de python c'est quand il n'y a plus d'étiquette sur une zone mémoire)
ect ...


Et c'est à cause de cette optimisation que vous tombez dans le piège, les "variables" (a et b) ne sont pas liées entre elles par l'affectation (b=a) mais par le faite qu'elle pointe sur la même zone mémoire. la liaison est donc dans le sens contraire

Python est capable même d'aller assez loin dans l'optimisation:

Code:

---

1 2 3 4 5 6

>>> a = "blabla" >>> hex(id(a)) '0x7ff801359720' >>> b = "blabla" >>> hex(id(b)) '0x7ff801359720'

---

même si vous ne faites pas une affectation direct (b=a) l’interpréteur python va regarder s'il n'existe pas déjà "blabla" en mémoire, et si oui faire pointer b vers cet object

par contre attention ce mécanisme n'est pas toujours utilisé car dans certains cas l'interpréteur conclu que ce sera tout aussi rapide de créer un nouvel object que de chercher s'il n'existe pas déjà
les critères de si oui ou non il faut vérifier sont gigantesques, tou d'abord ça dépend de l’interpréteur (CPython, celui de base ou bien IronPython par exemple) du type d'architecture matériel, de l'object en question, ect

Bonjour

Citation:

---

Envoyé par Personne3443

Un grand merci !

---

Il y a d'autres façons comme save=list(liste) (recréation d'une liste "à la volée" à partir de la variable "liste" et récupération de cette mémoire dans "save") ou bien save=liste[:] (utilisation des slices qui créent eux aussi des trucs en ram). Mais attention avec toutes ces méthodes car si la liste contient elle-même des éléments complexes (sous-listes, objets) alors on ne recopie que leurs "adresses".
Sinon il existe un module "copy" qui contient la fonction "deepcopy" qui, elle, se charge de tout dupliquer en récursif.

Citation:

---

Envoyé par Personne3443

C'est quand même bizarre tout ça...

---

990 fois sur 1000 on n'a pas besoin de dupliquer une liste (en effet, pouquoi faire ? La première ne suffit-elle pas ?).
Sur les 10 fois qui restent, dans 9 cas la duplication de l'adresse suffit (et c'est plus rapide de copier une simple adresse que tout un contenu). Ne reste qu'une fois sur 1000 où tu auras besoin de dupliquer le contenu d'une liste. Perso je trouve le truc plutôt bien pensé.

Citation:

---

Envoyé par flapili

Python est capable même d'aller assez loin dans l'optimisation:

Code:

---

1 2 3 4 5 6

>>> a = "blabla" >>> hex(id(a)) '0x7ff801359720' >>> b = "blabla" >>> hex(id(b)) '0x7ff801359720'

---

même si vous ne faites pas une affectation direct (b=a) l’interpréteur python va regarder s'il n'existe pas déjà "blabla" en mémoire, et si oui faire pointer b vers cet object

---

En fait c'est encore plus subtil que ça. Tente hex(id("blabla")) et je suis certain que tu auras '0x7ff801359720'. Quand tu écris "blabla" dans ton code pour quelque raison que ce soit (ex print("blabla")) la chaine est alors créée une fois dans le tas et ensuite a="blabla" ne fait qu'affecter cette adresse à "a" (tout comme en C quand tu écris char *c="blabla"). Enfin c'est comme ça que je le vois.

Mais ça ne fonctionne qu'avec des objets immuables (chaines, listes, ensembles). Si tu écris a=12345 puis b=12345 alors hex(id(a)) et hex(id(b)) n'auront pas la même valeur.

Citation:

---

Envoyé par Sve@r

En fait c'est encore plus fin que ça. Tente hex(id("blabla")) et je suis certain que tu auras '0x7ff801359720'. Quand tu écris "blabla" dans ton code pour quelque raison que ce soit (ex print("blabla")) la chaine est alors créée une fois dans le tas et ensuite a="blabla" ne fait qu'affecter cette adresse à "a" (tout comme en C quand tu écris char *c="blabla"). Enfin c'est comme ça que je le vois.

---

C'est également comme ça que je le vois avec CPython, cependant si regarder si l'object n'existe pas déjà est un comportement commun aux différents interpréteurs à ma connaissance je ne mettrais pas ma main à couper que c'est le cas pour tous.

De même ce mécanisme n'est pas toujours employé:
sur mon destop (Python 3.8.0 (tags/v3.8.0:fa919fd, Oct 14 2019, 19:37:50) [MSC v.1916 64 bit (AMD64)] on win32

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

>>> a = "a" >>> a is "a" True >>> b = "b!" >>> b is "b!" False >>> "a" is "a" True >>> "foo" is "foo" True >>> "foo!" is "foo!" True >>> foo = "foo!" >>> foo2 = "foo!" >>> foo is foo2 False >>> foo is "foo!" False >>> bar = "bar!" >>> bar2 = bar >>> bar2 is bar True

---

Je sais que avec CPython le char ! induit se comportement, je ne sais pas si c'est le cas avec une version 2.x, ou Jython/IronPython/ect

L'explication la plus détaillé que je connaisse est https://github.com/satwikkansal/wtfp...-explanation-2

Citation:

---

Envoyé par Sve@r

990 fois sur 1000 on n'a pas besoin de dupliquer une liste (en effet, pouquoi faire ? La première ne suffit-elle pas ?).
Sur les 10 fois qui restent, dans 9 cas la duplication de l'adresse suffit (et c'est plus rapide de copier une simple adresse que tout un contenu). Ne reste qu'une fois sur 1000 où tu auras besoin de dupliquer le contenu d'une liste. Perso je trouve le truc plutôt bien pensé.

---

C'est ma façon de coder qui ne doit pas être très optimiser :D...
En fait j'ai une base de données remplie de choix dans une liste. Il y a un choix a faire, certains choix ne sont plus possible a faire au moment de prendre la décision donc je copie la base de donnée et supprime les choix impossible pour gagner du temps dans la recherche du meilleur choix et garder ma base de donnée intacte pour les futures choix. C'est peut être moins optimiser mais plus claire pour moi.

Merci de toute ces réponses, on en apprend tout les jours grâce a ... developpez.net

Citation:

---

Envoyé par Personne3443

En fait j'ai une base de données remplie de choix dans une liste. Il y a un choix a faire, certains choix ne sont plus possible a faire au moment de prendre la décision donc je copie la base de donnée et supprime les choix impossible pour gagner du temps dans la recherche du meilleur choix et garder ma base de donnée intacte pour les futures choix.

---

Ok, j'admets, tu entres dans le cas où tu dois copier ta liste (enfin quand tu dis "bdd" j'imagine que c'est la liste de départ dont tu parles, et que tu ne veux pas modifier, parce que si vraiment tu avais une vraie bdd alors on ne serait plus dans le cas d'une liste à copier).
Il y a évidemment plusieurs façons de voir la chose mais perso je pense que moi je créerais la liste de choix à partir d'un traitement de la liste bdd initiale. Exemple

Code:

---

1 2 3 4

choix=[] for x in bdd: if x autorisé à faire partie du choix: choix.append(x) print("Voici les choix autorisés : ", choix)

---

Chose qu'on peut ensuite réduire grâce aux listes en intension: choix=tuple(x for x in bdd if x autorisé à faire partie du choix); print("Voici les choix autorisés : ", choix) 8-)

Citation:

---

Envoyé par flapili

Code:

---

1 2 3

>>> b = "b!" >>> b is "b!" False

---

---

Merde, chez-moi (Debian Buster, Python 3.7) c'est pareil !!! id(b) et id("b!") ne donnent pas le même résultat :calim2:

Citation:

---

Envoyé par Sve@r

Ok, j'admets, tu entres dans le cas où tu dois copier ta liste (enfin quand tu dis "bdd" j'imagine que c'est la liste de départ dont tu parles, et que tu ne veux pas modifier).
Il y a évidemment plusieurs façons de voir la chose mais perso je pense que moi je créerais la liste de choix à partir d'un traitement de la liste bdd initiale. Exemple

Code:

---

1 2 3 4

choix=[] for x in bdd: if x autorisé à faire partie du choix: choix.append(x) print("Voici les choix autorisés : ", choix)

---

Chose qu'on peut ensuite réduire grâce aux listes en intension: choix=tuple(x for x in bdd if x autorisé à faire partie du choix); print("Voici les choix autorisés : ", choix) 8-)

---

Pas con :D
Je pence que c'est ce que j’aurais fini par faire si je n'aurais pas trouver comment copier une liste correctement...

Merci de votre aide

vous pouvez également réfléchir avec des "ensembles" bien que les listes soient des ensembles, mais par là je veux dire que les set permettent de faire les opérations mathématiques usuelles sur les ensembles.
https://www.programiz.com/python-programming/set par exemple les schema pour les unions/intersection/ect devrait vous aider à visualiser dans un 1er temps.

vous n'êtes pas obligé de travaillé de bout en bout avec des set, vous pouvez au moment des opération à faire créer un set à partir de votre liste.

Code:

---

1 2 3 4 5 6 7 8 9 10 11

>>> ma_liste = [1, 2, 4, 6] >>> mon_set = set(ma_liste) >>> mon_set {1, 2, 4, 6} >>> ma_liste.pop() 6 >>> ma_liste [1, 2, 4] >>> mon_set {1, 2, 4, 6} >>>

---

par contre les set ordonnent également les éléments, il faut avoir ça en tête quand on les utilisent

Citation:

---

Envoyé par flapili

vous pouvez également réfléchir avec des "ensembles" bien que les listes soient des ensembles, mais par là je veux dire que les set permettent de faire les opérations mathématiques usuelles sur les ensembles.

---

Les ensembles apportent des avantages, mais ont leurs inconvénients inévitable. L'un d'entre eux est qu'on ne peut plus utiliser l'accès par indice ou slice car un ensemble n'est pas indexable.

Citation:

---

Envoyé par flapili

par contre les set ordonnent également les éléments,

---

Uniquement dès qu'ils dépassent 4 éléments

Code:

---

1 2 3 4 5 6

>>> a={1, 10, 2, 7} >>> a {1, 10, 2, 7} >>> a={1, 10, 2, 7, 4} >>> a {1, 2, 4, 7, 10}

---

:marteau: :D

Citation:

---

Envoyé par Sve@r

Uniquement dès qu'ils dépassent 4 éléments

Code:

---

1 2 3 4 5 6

>>> a={1, 10, 2, 7} >>> a {1, 10, 2, 7} >>> a={1, 10, 2, 7, 4} >>> a {1, 2, 4, 7, 10}

---

:marteau: :D

---

Je n'arrive pas à reproduire ce comportement sur mon pc (win10/py 3.8.0) ou sur mes vm (py 2.7.16 sur debian/centOS/alpine, 3.8.3 compilé depuis les sources sur debian, vm alpine 3.7 et container docker alpine 3.8.3)
tous ses environnements ont le point commun de tourner sous CPython

Code:

---

1 2 3 4 5 6 7 8 9

>>> a = {1, 3, 2} >>> a {1, 2, 3} >>> {1, 3, 2} {1, 2, 3} >>> {3, 2} {2, 3} >>> {"b", "a"} {'a', 'b'}

---

tu utilise quel interpréteur ?

Citation:

---

Envoyé par flapili

tu utilise quel interpréteur ?

---

Là j'étais sur Python 3.7.3 d'une Debian Buster (je crois que c'est la 10) qui me sert de machine principale de dev. Ce n'est pas la dernière des releases (je l'avais téléchargée en août dernier et jamais mise à jour depuis car elle est hors internet). Mais sur une Ubuntu 7.5 (Python 3.6.9) ça donne le même résultat. Je peux tester un Python plus élevé (3.8 comme toi) mais là ça va prendre plus de temps (faut que je le télécharge et le compile)...

Voici le même test sur Python 2.7.16 de la même Debian

Code:

---

1 2 3 4 5 6

>>> a={1, 10, 2, 7} >>> a set([1, 10, 2, 7]) >>> a={1, 10, 2, 7, 4} >>> a set([1, 10, 4, 2, 7])

---

[edit]Ok, téléchargé 3.8.5 pour zindow64 et testé sur une vm W10 64b: même résultat

Citation:

---

Envoyé par flapili

tous ses environnements ont le point commun de tourner sous CPython

---

héhé, peut-être que...

Ceci dit, l'important n'est pas ce que les tests donnent comme résultat ici ou là mais ce que dit la norme. Et là, la doc sur les ensembles dit bien "non ordonné" https://docs.python.org/fr/3/tutoria...ures.html#sets. Moi-même d'ailleurs n'aurais pas dû affirmer qu'ils étaient triés à partir de 5 car ce n'est pas ce que dit la doc (et je me suis laissé aller à l'enthousiasme).

je viens de découvrir que les set n'était pas "ordonné" par les valeurs mais par les hash des éléments. J'ai donc essayé ça

Code:

---

1 2 3 4 5

>>> l = [12, 5, 96, "abc"] >>> [hash(e) for e in l] [12, 5, 96, 4680045019504140335] >>> set(l) {96, 12, 5, 'abc'}

---

et .... je me suis senti con,

puis je suis tombé sur https://morepypy.blogspot.com/2015/0...-and-more.html, bien que ça n'engage que PyPy je me dis qu'il est tout à fait possible qu'une optimisation du même style doit intervenir dans les set, par contre je n'ai pas trouvé comment cette optimisation marchait chez moi, et quand bien même chez le voisin Jython ou PyPy ça serait implémenté de façon différente.
Je me suffirais de cette supposition :mrgreen: et avec en conclusion "l'ordre est défini par l'implémentation et les éléments du sets"