[Python, C++] Compréhension de la mémoire

Bonjour,

En python si on a deux variables $x$ et $y$ et que l’on effectue les opérations suivantes : $x = 1$, $y=x$ alors python ne va allouer qu’une seule case mémoire commune à $x$ et $y$, néanmoins ce n’est pas le cas en C++. Ma première question étant, cela a t-il seulement des avantages ? ou bien il y a des inconvénients à cette façon de gérer la mémoire ?

De plus en python on peut faire $a, b = b, a$, mais pas en C++ (si je ne me trompe pas). Je me demande alors comment fais python pour interchanger la valeur des variables au niveau de la mémoire ?

Merci d’avance. De plus si vous avez d’autres exemples ou des références sur la façon dont python gère la mémoire par rapport à des langages de plus bas niveaux comme C++, n’hésitez pas car cela m’intéresse beaucoup !

Salut,

En Python, c’est beaucoup plus compliqué que ça.

En Python, une variable est un nom qui pointe vers un objet. Et toute valeur est un objet : 1, None, True, "hello", [], …

Quand tu écris a = 1, l’interpréteur va commencer par créer un objet 1¹, puis créer une variable a qui va pointer vers 1.

Quand tu écris b = a, l’interpréteur ne va pas recréer d’objet. Il va juste créer une variable b qui va pointer vers là où pointe a. a et b vont pointer vers le même objet. Tu peux le vérifier avec a is b, qui retournera True.

Les objets ne se déplacent pas dans la mémoire, et ne changent pas de taille, et un objet est libéré uniquement lorsque plus aucun pointeur ne pointe vers lui.

Quand à a, b = b, a, en gros, c’est juste du sucre syntaxique pour ça :

1
2
3

tmp = a
a = b
b = tmp

Quand à C++, les variables ne sont pas toutes des pointeurs, et tout se comporte très différemment par rapport à Python.

1. En fait, si mes souvenirs sont bons, CPython créé des objets pour les petits entiers automatiquement dès son lancement qu’il met en cache de manière à ne pas recréer d’objet à chaque fois qu’on écrit 1. Pareil pour None, True et False : C’est toujours le même objet.

@motet-a ouaip, les entiers de 1 à 256 sont stockés à un endroit. D’ailleurs, il est même possible de les réécrirent (https://kate.io/blog/2017/08/22/weird-python-integers/).

Lu’!

@Universite : renseigne toi sur les notions de pile et de tas.

Pour le sucre syntaxique sur les pairs/tuple, en C++ ce sera std::tie et les fonctionnalités de <tuple>. Il y a aussi les structured bindings qui arrivent en C++17.

Pour répondre à la première question du PO : la façon qu’a Python de "gérer sa mémoire", ou plutôt le fait que le langage soit 100 % en passage par référence (parce que c’est de ça qu’on parle), est la plupart du temps un confort, mais peut parfois s’avérer piégeuse.

En fait il existe un certain nombre de pièges dans lesquels il faut tomber au moins une fois pour comprendre comment ça marche, du style copier une liste de listes naïvement et s’apercevoir que modifier la copie modifie aussi la liste d’origine.

En revanche, si on en est à la comparaison par rapport à C++, je dirais que le fait que tout soit passé par référence permet d’enlever de Python à peu près les trois quarts de la complexité de C++ : plus besoin de savoir si une instruction va copier ou non la donnée ou si une fonction doit accepter son argument par valeur ou par référence (ou par pointeur…), pas besoin de s’embêter avec la notion d’emprunt, le cycle de vie d’un objet est également rendu trivial. C’est comme si toutes les variables de Python étaient des std::shared_ptr<PyObject>.

En somme ce que ça a de "mieux" c’est surtout que c’est beaucoup plus simple. Par contre ce n’est pas une silver bullet : la complexité de C++ n’est pas gratuite, elle permet de donner certaines garanties lors de la compilation et de maîtriser ce qui se passe en mémoire lors de l’exécution. Quand on commence à avoir des problèmes de cet ordre-là en Python (où on a besoin de manipuler finement la mémoire, typiquement à cause d’une fuite de mémoire), c’est très rare, mais c’est mauvais signe parce que c’est le genre de truc que Python rend très chiant à débugger.

Tout est affaire de compromis.

Je ne suis pas vraiment d’accord sur ce point là. Ça revient à faire ce genre d’opération, oui.

Mais il s’agit plutôt d’un sucre syntaxique sur :

1
2

tmp = (a, b)
b, a = tmp

Car ce n’est qu’un cas particulier d’unpacking.

Ah, je me doutais bien que j’allais finir châtié sur ce point