Bonjour à tous,
J'ai quelques questions qui peut-être auront un rapport avec
l'implémentation, mais cela m'intéresse quand même.
1) Quand on fait
a = 2
b = a
Les deux variables a et b sont deux variables différentes,
la zone
mémoire allouée pour a et celle pour b sont distinctes.
Une modification
de a
n'affectera pas b etc. Chacun vit ça vie.
Ce qui me chagrine, c'est que id(a) et id(b) me donne exactement la même
valeur,
alors que, pour moi, a et b sont distinctes.
D'ailleurs quand je
modifie b (via b = 50 par exemple)
, là, ce petit coquin de Python ne me
donne plus le même id (et heureusement). Avez vous une explication ?
2) Pour les listes, c'est différent
et c'est bien dit dans les docs. Par
exemple :
l1 = [0,1,2,3,4]
l2 = l1
J'ai bien compris que "le nom l2 est un alias du nom l1" qui désigne le
même objet dans la mémoire de l'ordinateur. Une modification via l1 se
retrouvera en appelant la liste via l2. Par exemple :
l1[0] = 100
entraînera l2 de la forme [100,1,2,3,4]
Je voulais trouver une petite explication à cela. J'aimerais avoir votre
avis. Je me suis dit que, peut-être, l1 et l2 étaient des sortes de
pointeurs
(comme en C)
sur le premier élément de la liste.
3) J'ai lu ceci "avec a = 3, a est une référence, c'est-à-dire un nom
désignant l'emplacement mémoire d'une valeur (objet)".
Cela veut-il dire
qu'en fait les variables dans Python sont toutes "des pointeurs en C" ?
Bonjour à tous,
J'ai quelques questions qui peut-être auront un rapport avec
l'implémentation, mais cela m'intéresse quand même.
1) Quand on fait
a = 2
b = a
Les deux variables a et b sont deux variables différentes,
la zone
mémoire allouée pour a et celle pour b sont distinctes.
Une modification
de a
n'affectera pas b etc. Chacun vit ça vie.
Ce qui me chagrine, c'est que id(a) et id(b) me donne exactement la même
valeur,
alors que, pour moi, a et b sont distinctes.
D'ailleurs quand je
modifie b (via b = 50 par exemple)
, là, ce petit coquin de Python ne me
donne plus le même id (et heureusement). Avez vous une explication ?
2) Pour les listes, c'est différent
et c'est bien dit dans les docs. Par
exemple :
l1 = [0,1,2,3,4]
l2 = l1
J'ai bien compris que "le nom l2 est un alias du nom l1" qui désigne le
même objet dans la mémoire de l'ordinateur. Une modification via l1 se
retrouvera en appelant la liste via l2. Par exemple :
l1[0] = 100
entraînera l2 de la forme [100,1,2,3,4]
Je voulais trouver une petite explication à cela. J'aimerais avoir votre
avis. Je me suis dit que, peut-être, l1 et l2 étaient des sortes de
pointeurs
(comme en C)
sur le premier élément de la liste.
3) J'ai lu ceci "avec a = 3, a est une référence, c'est-à-dire un nom
désignant l'emplacement mémoire d'une valeur (objet)".
Cela veut-il dire
qu'en fait les variables dans Python sont toutes "des pointeurs en C" ?
Bonjour à tous,
J'ai quelques questions qui peut-être auront un rapport avec
l'implémentation, mais cela m'intéresse quand même.
1) Quand on fait
a = 2
b = a
Les deux variables a et b sont deux variables différentes,
la zone
mémoire allouée pour a et celle pour b sont distinctes.
Une modification
de a
n'affectera pas b etc. Chacun vit ça vie.
Ce qui me chagrine, c'est que id(a) et id(b) me donne exactement la même
valeur,
alors que, pour moi, a et b sont distinctes.
D'ailleurs quand je
modifie b (via b = 50 par exemple)
, là, ce petit coquin de Python ne me
donne plus le même id (et heureusement). Avez vous une explication ?
2) Pour les listes, c'est différent
et c'est bien dit dans les docs. Par
exemple :
l1 = [0,1,2,3,4]
l2 = l1
J'ai bien compris que "le nom l2 est un alias du nom l1" qui désigne le
même objet dans la mémoire de l'ordinateur. Une modification via l1 se
retrouvera en appelant la liste via l2. Par exemple :
l1[0] = 100
entraînera l2 de la forme [100,1,2,3,4]
Je voulais trouver une petite explication à cela. J'aimerais avoir votre
avis. Je me suis dit que, peut-être, l1 et l2 étaient des sortes de
pointeurs
(comme en C)
sur le premier élément de la liste.
3) J'ai lu ceci "avec a = 3, a est une référence, c'est-à-dire un nom
désignant l'emplacement mémoire d'une valeur (objet)".
Cela veut-il dire
qu'en fait les variables dans Python sont toutes "des pointeurs en C" ?
Si tu commences à raisonner avec les concepts du C, tu vas te faire du
mal pour rien. En Python, une variable n'est pas une étiquette sur une
adresse mémoire, c'est un nom associé à une référence sur un objet. Le
nom lui-même n'est rien d'autre que ça : un nom. Une clé dans une
table de hachage, si tu préfère (et accessoirement, hormis pour les
variables locales d'une fonction, c'est exactement ça : une clé dans
une table de hachage).
Quant à la zone mémoire où réside l'objet (les
zones mémoires, d'ailleurs, vu que c'est un type de donnée structuré
composé en partie de références sur d'autres objets...), c'est
l'affaire de la machine virtuelle. De ton point de vue, il pourrait
aussi bien être sur une tablette d'argile.
Donc,en bref, oublie les zones mémoires, et pense en termes d'objets.
Et dans ton cas, non, a et b référencent le *même* objet. En Python,
une assignation signifie "associe ce nom avec une référence sur cet
objet (ie : a = 2) ou sur l'objet référéncé par ce nom (ie: b = a)".
Un objet n'est *jamais* copié si tu ne le demande pas très
explicitement (en utilisant copy.copy() ou copy.deepcopy()).
Tu ne modifie pas 'b', tu le fait pointer sur un autre objet. Ce qui
est sans conséquence sur l'objet précédemment référencé par b (si ce
n'est de décrémemter son compteur de références).
Il y a une nette différence entre :
l1[0] = 100
et
l1 = 100
Le premier est en fait du sucre syntaxique pour
l1.__setitem__(0, 100)
Bref, un appel de méthode qui va modifier l'état de la liste
référencée par l1.
Je voulais trouver une petite explication à cela. J'aimerais avoir votre
avis. Je me suis dit que, peut-être, l1 et l2 étaient des sortes de
pointeurs
une référence(comme en C)
en l'occurence, comme en C++ ou en Javasur le premier élément de la liste.
sur l'objet liste.
En Python, tu n'a *que* des références sur des objets, *jamais* de
types 'immédiat' comme en C. Ne laisse pas la syntaxe te tromper, ce
n'est pas parce que tu définis un objet via une expression littérale
que tu a autre chose qu'une référence sur un objet.
Cela veut-il dire
qu'en fait les variables dans Python sont toutes "des pointeurs en C" ?
Non, même pas. Une variable C de type pointeur contient une adresse
mémoire. Un nom ne contient rien - une clé dans une table de hachage
ne contient rien.
Si tu commences à raisonner avec les concepts du C, tu vas te faire du
mal pour rien. En Python, une variable n'est pas une étiquette sur une
adresse mémoire, c'est un nom associé à une référence sur un objet. Le
nom lui-même n'est rien d'autre que ça : un nom. Une clé dans une
table de hachage, si tu préfère (et accessoirement, hormis pour les
variables locales d'une fonction, c'est exactement ça : une clé dans
une table de hachage).
Quant à la zone mémoire où réside l'objet (les
zones mémoires, d'ailleurs, vu que c'est un type de donnée structuré
composé en partie de références sur d'autres objets...), c'est
l'affaire de la machine virtuelle. De ton point de vue, il pourrait
aussi bien être sur une tablette d'argile.
Donc,en bref, oublie les zones mémoires, et pense en termes d'objets.
Et dans ton cas, non, a et b référencent le *même* objet. En Python,
une assignation signifie "associe ce nom avec une référence sur cet
objet (ie : a = 2) ou sur l'objet référéncé par ce nom (ie: b = a)".
Un objet n'est *jamais* copié si tu ne le demande pas très
explicitement (en utilisant copy.copy() ou copy.deepcopy()).
Tu ne modifie pas 'b', tu le fait pointer sur un autre objet. Ce qui
est sans conséquence sur l'objet précédemment référencé par b (si ce
n'est de décrémemter son compteur de références).
Il y a une nette différence entre :
l1[0] = 100
et
l1 = 100
Le premier est en fait du sucre syntaxique pour
l1.__setitem__(0, 100)
Bref, un appel de méthode qui va modifier l'état de la liste
référencée par l1.
Je voulais trouver une petite explication à cela. J'aimerais avoir votre
avis. Je me suis dit que, peut-être, l1 et l2 étaient des sortes de
pointeurs
une référence
(comme en C)
en l'occurence, comme en C++ ou en Java
sur le premier élément de la liste.
sur l'objet liste.
En Python, tu n'a *que* des références sur des objets, *jamais* de
types 'immédiat' comme en C. Ne laisse pas la syntaxe te tromper, ce
n'est pas parce que tu définis un objet via une expression littérale
que tu a autre chose qu'une référence sur un objet.
Cela veut-il dire
qu'en fait les variables dans Python sont toutes "des pointeurs en C" ?
Non, même pas. Une variable C de type pointeur contient une adresse
mémoire. Un nom ne contient rien - une clé dans une table de hachage
ne contient rien.
Si tu commences à raisonner avec les concepts du C, tu vas te faire du
mal pour rien. En Python, une variable n'est pas une étiquette sur une
adresse mémoire, c'est un nom associé à une référence sur un objet. Le
nom lui-même n'est rien d'autre que ça : un nom. Une clé dans une
table de hachage, si tu préfère (et accessoirement, hormis pour les
variables locales d'une fonction, c'est exactement ça : une clé dans
une table de hachage).
Quant à la zone mémoire où réside l'objet (les
zones mémoires, d'ailleurs, vu que c'est un type de donnée structuré
composé en partie de références sur d'autres objets...), c'est
l'affaire de la machine virtuelle. De ton point de vue, il pourrait
aussi bien être sur une tablette d'argile.
Donc,en bref, oublie les zones mémoires, et pense en termes d'objets.
Et dans ton cas, non, a et b référencent le *même* objet. En Python,
une assignation signifie "associe ce nom avec une référence sur cet
objet (ie : a = 2) ou sur l'objet référéncé par ce nom (ie: b = a)".
Un objet n'est *jamais* copié si tu ne le demande pas très
explicitement (en utilisant copy.copy() ou copy.deepcopy()).
Tu ne modifie pas 'b', tu le fait pointer sur un autre objet. Ce qui
est sans conséquence sur l'objet précédemment référencé par b (si ce
n'est de décrémemter son compteur de références).
Il y a une nette différence entre :
l1[0] = 100
et
l1 = 100
Le premier est en fait du sucre syntaxique pour
l1.__setitem__(0, 100)
Bref, un appel de méthode qui va modifier l'état de la liste
référencée par l1.
Je voulais trouver une petite explication à cela. J'aimerais avoir votre
avis. Je me suis dit que, peut-être, l1 et l2 étaient des sortes de
pointeurs
une référence(comme en C)
en l'occurence, comme en C++ ou en Javasur le premier élément de la liste.
sur l'objet liste.
En Python, tu n'a *que* des références sur des objets, *jamais* de
types 'immédiat' comme en C. Ne laisse pas la syntaxe te tromper, ce
n'est pas parce que tu définis un objet via une expression littérale
que tu a autre chose qu'une référence sur un objet.
Cela veut-il dire
qu'en fait les variables dans Python sont toutes "des pointeurs en C" ?
Non, même pas. Une variable C de type pointeur contient une adresse
mémoire. Un nom ne contient rien - une clé dans une table de hachage
ne contient rien.
Il y a une nette différence entre :
l1[0] = 100
et
l1 = 100
Le premier est en fait du sucre syntaxique pour
l1.__setitem__(0, 100)
Bref, un appel de méthode qui va modifier l'état de la liste
référencée par l1.
Ok, on garde une certaine cohérence sur le tout objet : avec [], on
applique sans le savoir une méthode à l'objet l1. Tu ne l'as pas précisé
mais avec l1 = 100, évidemment, on réassigne l1 vers un nouvel objet qui
n'est plus une liste.
Il y a une nette différence entre :
l1[0] = 100
et
l1 = 100
Le premier est en fait du sucre syntaxique pour
l1.__setitem__(0, 100)
Bref, un appel de méthode qui va modifier l'état de la liste
référencée par l1.
Ok, on garde une certaine cohérence sur le tout objet : avec [], on
applique sans le savoir une méthode à l'objet l1. Tu ne l'as pas précisé
mais avec l1 = 100, évidemment, on réassigne l1 vers un nouvel objet qui
n'est plus une liste.
Il y a une nette différence entre :
l1[0] = 100
et
l1 = 100
Le premier est en fait du sucre syntaxique pour
l1.__setitem__(0, 100)
Bref, un appel de méthode qui va modifier l'état de la liste
référencée par l1.
Ok, on garde une certaine cohérence sur le tout objet : avec [], on
applique sans le savoir une méthode à l'objet l1. Tu ne l'as pas précisé
mais avec l1 = 100, évidemment, on réassigne l1 vers un nouvel objet qui
n'est plus une liste.
b[0] = 7 # ce n'est pas une assignation
b[0] = 7 # ce n'est pas une assignation
b[0] = 7 # ce n'est pas une assignation
Déjà, grand merci pour toutes tes explications.Si tu commences à raisonner avec les concepts du C, tu vas te faire du
mal pour rien. En Python, une variable n'est pas une étiquette sur une
adresse mémoire, c'est un nom associé à une référence sur un o bjet. Le
nom lui-même n'est rien d'autre que ça : un nom. Une clé dans une
table de hachage, si tu préfère (et accessoirement, hormis pour les
variables locales d'une fonction, c'est exactement ça : une clé dans
une table de hachage).
Ah oui, tiens, et les variables locales d'une fonctions ? C'est aussi un
nom associé à une référence sauf que l'espace des noms dans lequel elle
se trouve est dans un espace temporaire disjoint de l'espace de nom du
script principal ?
Quant à la zone mémoire où réside l'objet (les
zones mémoires, d'ailleurs, vu que c'est un type de donnée structur é
composé en partie de références sur d'autres objets...), c'est
l'affaire de la machine virtuelle. De ton point de vue, il pourrait
aussi bien être sur une tablette d'argile.
Je comprends cette logique : il faut rester dans le cadre du langage
abstrait et ne pas rentrer dans l'implémentation. Tu as raison. Mais,
dès fois, je trouve que rentrer (un tout petit peu) dans
l'implémentation, ça m'aide à comprendre.
Donc,en bref, oublie les zones mémoires, et pense en termes d'objets.
Et dans ton cas, non, a et b référencent le *même* objet. En Pytho n,
une assignation signifie "associe ce nom avec une référence sur cet
objet (ie : a = 2) ou sur l'objet référéncé par ce nom (ie: b = a)".
Un objet n'est *jamais* copié si tu ne le demande pas très
explicitement (en utilisant copy.copy() ou copy.deepcopy()).
Là, je crois que *tout* est dit dans ce paragraphe très clair. Je ré sume
pour voir.
1) En *C*, une variable est un objet (un peu au sens de Python, avec un
type [taille + façon d'être interprété], une adresse et une valeur ). On
peut donc parler de l'adresse d'une variable. Deux variables avec des
noms différents ont chacune une adresse différente.
2) Avec *Python*, une variable est un simple nom faisant référence à un
objet (avec un type [taille + façon d'être interprété],
une adresse et
une valeur). Une variable n'a pas d'adresse. Deux variables avec des
noms différents peuvent très bien référencer un même objet.
Par exemple avec ceci (en Python)
a=1
b=1
c=1
finalement, dans la mémoire se trouve un seul objet créé (l'entier 1 ).
Alors qu'avec l'équivalent en C, trois objets seraient crées (de mêm e
valeur, mais à trois endroits différents).
Si j'ai bon, je crois que j'ai franchi un petit cap dans ma
compréhension de Python. :-)
Remarque en passant : Je me doutais bien que d'un langage à un autre,
des mêmes notions pouvaient avoir une implémentation différente. Mai s
quand même, je n'imaginais pas que cela serait le cas pour la basique
notion de variable par exemple !
J'espère que d'un langage à un autre,
il ne faut pas tout réapprendre à chaque fois (car là, finalement, j 'ai
du réapprendre ce qu'est une variable :-) ) ?
Tu ne modifie pas 'b', tu le fait pointer sur un autre objet. Ce qui
est sans conséquence sur l'objet précédemment référencé par b (si ce
n'est de décrémemter son compteur de références).
D'accord. Dans mes autres messages, j'ai du écrire cette erreur 20 fois.
Je crois que c'est compris. Ce qui m'intéresse ici, c'est la notion de
compteur de référence. Chaque objet possède un compteur de référ ence,
c'est-à-dire, si je comprends bien, un compteur qui donne le nombre de
variable qui font référence à cet objet. C'est ça ?
Heu ..., mais ça sert à quoi ? À effacer l'objet de la mémoire qua nd le
compteur est à 0 peut-être ?
Il y a une nette différence entre :
l1[0] = 100
et
l1 = 100
Le premier est en fait du sucre syntaxique pour
l1.__setitem__(0, 100)
Bref, un appel de méthode qui va modifier l'état de la liste
référencée par l1.
Ok, on garde une certaine cohérence sur le tout objet : avec [], on
applique sans le savoir
une méthode à l'objet l1. Tu ne l'as pas précisé
mais avec l1 = 100, évidemment, on réassigne l1 vers un nouvel objet qui
n'est plus une liste.
Je voulais trouver une petite explication à cela. J'aimerais avoir vo tre
avis. Je me suis dit que, peut-être, l1 et l2 étaient des sortes de
pointeurs
une référence(comme en C)
en l'occurence, comme en C++ ou en Javasur le premier élément de la liste.
sur l'objet liste.
Ok, ok. Allez, quand même, en interne de chez interne (dans le code C de
CPython par exemple), il n'y a pas de pointeur qui traîne quelque part
dans la définition d'une variable Python ? Hein, pour me faire plaisir. :-)
En Python, tu n'a *que* des références sur des objets, *jamais* de
types 'immédiat' comme en C. Ne laisse pas la syntaxe te tromper, ce
n'est pas parce que tu définis un objet via une expression littérale
que tu a autre chose qu'une référence sur un objet.
Heu, un type immédiat c'est quoi ?
Cela veut-il dire
qu'en fait les variables dans Python sont toutes "des pointeurs en C" ?
Non, même pas. Une variable C de type pointeur contient une adresse
mémoire. Un nom ne contient rien - une clé dans une table de hachag e
ne contient rien.
Allez, il n'y a pas un petit pointeur caché quelque part ...
Déjà, grand merci pour toutes tes explications.
Si tu commences à raisonner avec les concepts du C, tu vas te faire du
mal pour rien. En Python, une variable n'est pas une étiquette sur une
adresse mémoire, c'est un nom associé à une référence sur un o bjet. Le
nom lui-même n'est rien d'autre que ça : un nom. Une clé dans une
table de hachage, si tu préfère (et accessoirement, hormis pour les
variables locales d'une fonction, c'est exactement ça : une clé dans
une table de hachage).
Ah oui, tiens, et les variables locales d'une fonctions ? C'est aussi un
nom associé à une référence sauf que l'espace des noms dans lequel elle
se trouve est dans un espace temporaire disjoint de l'espace de nom du
script principal ?
Quant à la zone mémoire où réside l'objet (les
zones mémoires, d'ailleurs, vu que c'est un type de donnée structur é
composé en partie de références sur d'autres objets...), c'est
l'affaire de la machine virtuelle. De ton point de vue, il pourrait
aussi bien être sur une tablette d'argile.
Je comprends cette logique : il faut rester dans le cadre du langage
abstrait et ne pas rentrer dans l'implémentation. Tu as raison. Mais,
dès fois, je trouve que rentrer (un tout petit peu) dans
l'implémentation, ça m'aide à comprendre.
Donc,en bref, oublie les zones mémoires, et pense en termes d'objets.
Et dans ton cas, non, a et b référencent le *même* objet. En Pytho n,
une assignation signifie "associe ce nom avec une référence sur cet
objet (ie : a = 2) ou sur l'objet référéncé par ce nom (ie: b = a)".
Un objet n'est *jamais* copié si tu ne le demande pas très
explicitement (en utilisant copy.copy() ou copy.deepcopy()).
Là, je crois que *tout* est dit dans ce paragraphe très clair. Je ré sume
pour voir.
1) En *C*, une variable est un objet (un peu au sens de Python, avec un
type [taille + façon d'être interprété], une adresse et une valeur ). On
peut donc parler de l'adresse d'une variable. Deux variables avec des
noms différents ont chacune une adresse différente.
2) Avec *Python*, une variable est un simple nom faisant référence à un
objet (avec un type [taille + façon d'être interprété],
une adresse et
une valeur). Une variable n'a pas d'adresse. Deux variables avec des
noms différents peuvent très bien référencer un même objet.
Par exemple avec ceci (en Python)
a=1
b=1
c=1
finalement, dans la mémoire se trouve un seul objet créé (l'entier 1 ).
Alors qu'avec l'équivalent en C, trois objets seraient crées (de mêm e
valeur, mais à trois endroits différents).
Si j'ai bon, je crois que j'ai franchi un petit cap dans ma
compréhension de Python. :-)
Remarque en passant : Je me doutais bien que d'un langage à un autre,
des mêmes notions pouvaient avoir une implémentation différente. Mai s
quand même, je n'imaginais pas que cela serait le cas pour la basique
notion de variable par exemple !
J'espère que d'un langage à un autre,
il ne faut pas tout réapprendre à chaque fois (car là, finalement, j 'ai
du réapprendre ce qu'est une variable :-) ) ?
Tu ne modifie pas 'b', tu le fait pointer sur un autre objet. Ce qui
est sans conséquence sur l'objet précédemment référencé par b (si ce
n'est de décrémemter son compteur de références).
D'accord. Dans mes autres messages, j'ai du écrire cette erreur 20 fois.
Je crois que c'est compris. Ce qui m'intéresse ici, c'est la notion de
compteur de référence. Chaque objet possède un compteur de référ ence,
c'est-à-dire, si je comprends bien, un compteur qui donne le nombre de
variable qui font référence à cet objet. C'est ça ?
Heu ..., mais ça sert à quoi ? À effacer l'objet de la mémoire qua nd le
compteur est à 0 peut-être ?
Il y a une nette différence entre :
l1[0] = 100
et
l1 = 100
Le premier est en fait du sucre syntaxique pour
l1.__setitem__(0, 100)
Bref, un appel de méthode qui va modifier l'état de la liste
référencée par l1.
Ok, on garde une certaine cohérence sur le tout objet : avec [], on
applique sans le savoir
une méthode à l'objet l1. Tu ne l'as pas précisé
mais avec l1 = 100, évidemment, on réassigne l1 vers un nouvel objet qui
n'est plus une liste.
Je voulais trouver une petite explication à cela. J'aimerais avoir vo tre
avis. Je me suis dit que, peut-être, l1 et l2 étaient des sortes de
pointeurs
une référence
(comme en C)
en l'occurence, comme en C++ ou en Java
sur le premier élément de la liste.
sur l'objet liste.
Ok, ok. Allez, quand même, en interne de chez interne (dans le code C de
CPython par exemple), il n'y a pas de pointeur qui traîne quelque part
dans la définition d'une variable Python ? Hein, pour me faire plaisir. :-)
En Python, tu n'a *que* des références sur des objets, *jamais* de
types 'immédiat' comme en C. Ne laisse pas la syntaxe te tromper, ce
n'est pas parce que tu définis un objet via une expression littérale
que tu a autre chose qu'une référence sur un objet.
Heu, un type immédiat c'est quoi ?
Cela veut-il dire
qu'en fait les variables dans Python sont toutes "des pointeurs en C" ?
Non, même pas. Une variable C de type pointeur contient une adresse
mémoire. Un nom ne contient rien - une clé dans une table de hachag e
ne contient rien.
Allez, il n'y a pas un petit pointeur caché quelque part ...
Déjà, grand merci pour toutes tes explications.Si tu commences à raisonner avec les concepts du C, tu vas te faire du
mal pour rien. En Python, une variable n'est pas une étiquette sur une
adresse mémoire, c'est un nom associé à une référence sur un o bjet. Le
nom lui-même n'est rien d'autre que ça : un nom. Une clé dans une
table de hachage, si tu préfère (et accessoirement, hormis pour les
variables locales d'une fonction, c'est exactement ça : une clé dans
une table de hachage).
Ah oui, tiens, et les variables locales d'une fonctions ? C'est aussi un
nom associé à une référence sauf que l'espace des noms dans lequel elle
se trouve est dans un espace temporaire disjoint de l'espace de nom du
script principal ?
Quant à la zone mémoire où réside l'objet (les
zones mémoires, d'ailleurs, vu que c'est un type de donnée structur é
composé en partie de références sur d'autres objets...), c'est
l'affaire de la machine virtuelle. De ton point de vue, il pourrait
aussi bien être sur une tablette d'argile.
Je comprends cette logique : il faut rester dans le cadre du langage
abstrait et ne pas rentrer dans l'implémentation. Tu as raison. Mais,
dès fois, je trouve que rentrer (un tout petit peu) dans
l'implémentation, ça m'aide à comprendre.
Donc,en bref, oublie les zones mémoires, et pense en termes d'objets.
Et dans ton cas, non, a et b référencent le *même* objet. En Pytho n,
une assignation signifie "associe ce nom avec une référence sur cet
objet (ie : a = 2) ou sur l'objet référéncé par ce nom (ie: b = a)".
Un objet n'est *jamais* copié si tu ne le demande pas très
explicitement (en utilisant copy.copy() ou copy.deepcopy()).
Là, je crois que *tout* est dit dans ce paragraphe très clair. Je ré sume
pour voir.
1) En *C*, une variable est un objet (un peu au sens de Python, avec un
type [taille + façon d'être interprété], une adresse et une valeur ). On
peut donc parler de l'adresse d'une variable. Deux variables avec des
noms différents ont chacune une adresse différente.
2) Avec *Python*, une variable est un simple nom faisant référence à un
objet (avec un type [taille + façon d'être interprété],
une adresse et
une valeur). Une variable n'a pas d'adresse. Deux variables avec des
noms différents peuvent très bien référencer un même objet.
Par exemple avec ceci (en Python)
a=1
b=1
c=1
finalement, dans la mémoire se trouve un seul objet créé (l'entier 1 ).
Alors qu'avec l'équivalent en C, trois objets seraient crées (de mêm e
valeur, mais à trois endroits différents).
Si j'ai bon, je crois que j'ai franchi un petit cap dans ma
compréhension de Python. :-)
Remarque en passant : Je me doutais bien que d'un langage à un autre,
des mêmes notions pouvaient avoir une implémentation différente. Mai s
quand même, je n'imaginais pas que cela serait le cas pour la basique
notion de variable par exemple !
J'espère que d'un langage à un autre,
il ne faut pas tout réapprendre à chaque fois (car là, finalement, j 'ai
du réapprendre ce qu'est une variable :-) ) ?
Tu ne modifie pas 'b', tu le fait pointer sur un autre objet. Ce qui
est sans conséquence sur l'objet précédemment référencé par b (si ce
n'est de décrémemter son compteur de références).
D'accord. Dans mes autres messages, j'ai du écrire cette erreur 20 fois.
Je crois que c'est compris. Ce qui m'intéresse ici, c'est la notion de
compteur de référence. Chaque objet possède un compteur de référ ence,
c'est-à-dire, si je comprends bien, un compteur qui donne le nombre de
variable qui font référence à cet objet. C'est ça ?
Heu ..., mais ça sert à quoi ? À effacer l'objet de la mémoire qua nd le
compteur est à 0 peut-être ?
Il y a une nette différence entre :
l1[0] = 100
et
l1 = 100
Le premier est en fait du sucre syntaxique pour
l1.__setitem__(0, 100)
Bref, un appel de méthode qui va modifier l'état de la liste
référencée par l1.
Ok, on garde une certaine cohérence sur le tout objet : avec [], on
applique sans le savoir
une méthode à l'objet l1. Tu ne l'as pas précisé
mais avec l1 = 100, évidemment, on réassigne l1 vers un nouvel objet qui
n'est plus une liste.
Je voulais trouver une petite explication à cela. J'aimerais avoir vo tre
avis. Je me suis dit que, peut-être, l1 et l2 étaient des sortes de
pointeurs
une référence(comme en C)
en l'occurence, comme en C++ ou en Javasur le premier élément de la liste.
sur l'objet liste.
Ok, ok. Allez, quand même, en interne de chez interne (dans le code C de
CPython par exemple), il n'y a pas de pointeur qui traîne quelque part
dans la définition d'une variable Python ? Hein, pour me faire plaisir. :-)
En Python, tu n'a *que* des références sur des objets, *jamais* de
types 'immédiat' comme en C. Ne laisse pas la syntaxe te tromper, ce
n'est pas parce que tu définis un objet via une expression littérale
que tu a autre chose qu'une référence sur un objet.
Heu, un type immédiat c'est quoi ?
Cela veut-il dire
qu'en fait les variables dans Python sont toutes "des pointeurs en C" ?
Non, même pas. Une variable C de type pointeur contient une adresse
mémoire. Un nom ne contient rien - une clé dans une table de hachag e
ne contient rien.
Allez, il n'y a pas un petit pointeur caché quelque part ...
b[0] = 7 # ce n'est pas une assignation
Bon, là j'exagère un peu. b[0]=7 est (je pense) une assignation du
premier élément de l'objet séquence référencé par a (ou par b), mais ce
n'est pas une modification de l'objet 0 (ancien objet référencé par
b[0]) mais plutôt une création d'une référence de b[0] vers le nouvel
objet 7. Cette réassignation, de fait, entraîne une modification de
l'objet séquence référencé par b et aussi par a.
b[0] = 7 # ce n'est pas une assignation
Bon, là j'exagère un peu. b[0]=7 est (je pense) une assignation du
premier élément de l'objet séquence référencé par a (ou par b), mais ce
n'est pas une modification de l'objet 0 (ancien objet référencé par
b[0]) mais plutôt une création d'une référence de b[0] vers le nouvel
objet 7. Cette réassignation, de fait, entraîne une modification de
l'objet séquence référencé par b et aussi par a.
b[0] = 7 # ce n'est pas une assignation
Bon, là j'exagère un peu. b[0]=7 est (je pense) une assignation du
premier élément de l'objet séquence référencé par a (ou par b), mais ce
n'est pas une modification de l'objet 0 (ancien objet référencé par
b[0]) mais plutôt une création d'une référence de b[0] vers le nouvel
objet 7. Cette réassignation, de fait, entraîne une modification de
l'objet séquence référencé par b et aussi par a.
Plus j'y pense, plus je me dis que la syntaxe l1[0]0 est vraiment
traître. Elle fait vraiment penser à une réassignation comme l1 = 100,
alors qu'en fait c'est une méthode appliquée à un objet ("mutable") pour
le modifier (évidemment la syntaxe l1[0]0 est quand même
incontournable du point de vue pratique). C'est ça qui m'a induit en
erreur :
a = 2
b = a # a et b font référence au même objet
b = 5 # c'est une assignation de b vers un nouvel objet
# ce n'est pas une modification de l'objet référencé
# par b qui est non mutable
print a # donne 2
print b # donne 5 car b ne se réfère plus au même objet que a
a = [0,1,2,3]
b = a # a et b font référence au même objet
b[0] = 7 # ce n'est pas une assignation
# c'est une modification de l'objet (mutable)
# référencé par b, via une méthode
print a # donne [7,1,2,3] l'objet référencé par a et b est le
# même et il a subi une modification en cours de route
print b # donne [7,1,2,3]
Une réassignation ne modifie pas un objet, mais créé une référen ce vers
un nouvel objet. On peut modifier un objet, à condition qu'il soit
mutable, mais cela ne peut pas passer par une réassignation. Par une
méthode par exemple.
Et b[0]=7, n'est pas une réassignation mais une
méthode cachée (la bougresse).
Plus j'y pense, plus je me dis que la syntaxe l1[0]=100 est vraiment
traître. Elle fait vraiment penser à une réassignation comme l1 = 100,
alors qu'en fait c'est une méthode appliquée à un objet ("mutable") pour
le modifier (évidemment la syntaxe l1[0]=100 est quand même
incontournable du point de vue pratique). C'est ça qui m'a induit en
erreur :
a = 2
b = a # a et b font référence au même objet
b = 5 # c'est une assignation de b vers un nouvel objet
# ce n'est pas une modification de l'objet référencé
# par b qui est non mutable
print a # donne 2
print b # donne 5 car b ne se réfère plus au même objet que a
a = [0,1,2,3]
b = a # a et b font référence au même objet
b[0] = 7 # ce n'est pas une assignation
# c'est une modification de l'objet (mutable)
# référencé par b, via une méthode
print a # donne [7,1,2,3] l'objet référencé par a et b est le
# même et il a subi une modification en cours de route
print b # donne [7,1,2,3]
Une réassignation ne modifie pas un objet, mais créé une référen ce vers
un nouvel objet. On peut modifier un objet, à condition qu'il soit
mutable, mais cela ne peut pas passer par une réassignation. Par une
méthode par exemple.
Et b[0]=7, n'est pas une réassignation mais une
méthode cachée (la bougresse).
Plus j'y pense, plus je me dis que la syntaxe l1[0]0 est vraiment
traître. Elle fait vraiment penser à une réassignation comme l1 = 100,
alors qu'en fait c'est une méthode appliquée à un objet ("mutable") pour
le modifier (évidemment la syntaxe l1[0]0 est quand même
incontournable du point de vue pratique). C'est ça qui m'a induit en
erreur :
a = 2
b = a # a et b font référence au même objet
b = 5 # c'est une assignation de b vers un nouvel objet
# ce n'est pas une modification de l'objet référencé
# par b qui est non mutable
print a # donne 2
print b # donne 5 car b ne se réfère plus au même objet que a
a = [0,1,2,3]
b = a # a et b font référence au même objet
b[0] = 7 # ce n'est pas une assignation
# c'est une modification de l'objet (mutable)
# référencé par b, via une méthode
print a # donne [7,1,2,3] l'objet référencé par a et b est le
# même et il a subi une modification en cours de route
print b # donne [7,1,2,3]
Une réassignation ne modifie pas un objet, mais créé une référen ce vers
un nouvel objet. On peut modifier un objet, à condition qu'il soit
mutable, mais cela ne peut pas passer par une réassignation. Par une
méthode par exemple.
Et b[0]=7, n'est pas une réassignation mais une
méthode cachée (la bougresse).
b[0] = 7 # ce n'est pas une assignation
Bon, là j'exagère un peu. b[0]=7 est (je pense) une assignation du
premier élément de l'objet séquence référencé par a (ou par b),
mais ce
n'est pas une modification de l'objet 0 (ancien objet référencé pa r
b[0]) mais plutôt une création d'une référence de b[0] vers le n ouvel
objet 7.
Cette réassignation, de fait, entraîne une modification de
l'objet séquence référencé par b et aussi par a.
Il y en a au moins un qui se couchera plus savant cette nuit.
b[0] = 7 # ce n'est pas une assignation
Bon, là j'exagère un peu. b[0]=7 est (je pense) une assignation du
premier élément de l'objet séquence référencé par a (ou par b),
mais ce
n'est pas une modification de l'objet 0 (ancien objet référencé pa r
b[0]) mais plutôt une création d'une référence de b[0] vers le n ouvel
objet 7.
Cette réassignation, de fait, entraîne une modification de
l'objet séquence référencé par b et aussi par a.
Il y en a au moins un qui se couchera plus savant cette nuit.
b[0] = 7 # ce n'est pas une assignation
Bon, là j'exagère un peu. b[0]=7 est (je pense) une assignation du
premier élément de l'objet séquence référencé par a (ou par b),
mais ce
n'est pas une modification de l'objet 0 (ancien objet référencé pa r
b[0]) mais plutôt une création d'une référence de b[0] vers le n ouvel
objet 7.
Cette réassignation, de fait, entraîne une modification de
l'objet séquence référencé par b et aussi par a.
Il y en a au moins un qui se couchera plus savant cette nuit.
On 9 avr, 02:29, Francois wrote:
(snip)Plus j'y pense, plus je me dis que la syntaxe l1[0]0 est vraiment
traître. Elle fait vraiment penser à une réassignation comme l1 = 100,
alors qu'en fait c'est une méthode appliquée à un objet ("mutable") pour
le modifier (évidemment la syntaxe l1[0]0 est quand même
incontournable du point de vue pratique). C'est ça qui m'a induit en
erreur :
T'inquiètes pas, t'es pas le premier (et c'est pas non plus la
première fois que j'explique ça).
Une réassignation ne modifie pas un objet, mais créé une référence vers
un nouvel objet. On peut modifier un objet, à condition qu'il soit
mutable, mais cela ne peut pas passer par une réassignation. Par une
méthode par exemple.
Par une méthode uniquement. Même si l'appel de méthode n'est pas
explicite.
Et b[0]=7, n'est pas une réassignation mais une
méthode cachée (la bougresse).
Certes, mais elle est tellement plus élégante comme ça qu'on lui
pardonne !-)
Bon, je crois que t'es bon, là.
On 9 avr, 02:29, Francois <mathsatta...@free.fr> wrote:
(snip)
Plus j'y pense, plus je me dis que la syntaxe l1[0]0 est vraiment
traître. Elle fait vraiment penser à une réassignation comme l1 = 100,
alors qu'en fait c'est une méthode appliquée à un objet ("mutable") pour
le modifier (évidemment la syntaxe l1[0]0 est quand même
incontournable du point de vue pratique). C'est ça qui m'a induit en
erreur :
T'inquiètes pas, t'es pas le premier (et c'est pas non plus la
première fois que j'explique ça).
Une réassignation ne modifie pas un objet, mais créé une référence vers
un nouvel objet. On peut modifier un objet, à condition qu'il soit
mutable, mais cela ne peut pas passer par une réassignation. Par une
méthode par exemple.
Par une méthode uniquement. Même si l'appel de méthode n'est pas
explicite.
Et b[0]=7, n'est pas une réassignation mais une
méthode cachée (la bougresse).
Certes, mais elle est tellement plus élégante comme ça qu'on lui
pardonne !-)
Bon, je crois que t'es bon, là.
On 9 avr, 02:29, Francois wrote:
(snip)Plus j'y pense, plus je me dis que la syntaxe l1[0]0 est vraiment
traître. Elle fait vraiment penser à une réassignation comme l1 = 100,
alors qu'en fait c'est une méthode appliquée à un objet ("mutable") pour
le modifier (évidemment la syntaxe l1[0]0 est quand même
incontournable du point de vue pratique). C'est ça qui m'a induit en
erreur :
T'inquiètes pas, t'es pas le premier (et c'est pas non plus la
première fois que j'explique ça).
Une réassignation ne modifie pas un objet, mais créé une référence vers
un nouvel objet. On peut modifier un objet, à condition qu'il soit
mutable, mais cela ne peut pas passer par une réassignation. Par une
méthode par exemple.
Par une méthode uniquement. Même si l'appel de méthode n'est pas
explicite.
Et b[0]=7, n'est pas une réassignation mais une
méthode cachée (la bougresse).
Certes, mais elle est tellement plus élégante comme ça qu'on lui
pardonne !-)
Bon, je crois que t'es bon, là.
On 9 avr, 01:12, Francois wrote:Ah oui, tiens, et les variables locales d'une fonctions ? C'est aussi un
nom associé à une référence sauf que l'espace des noms dans lequel elle
se trouve est dans un espace temporaire disjoint de l'espace de nom du
script principal ?
Exactement. Note bien que ce sont les *noms* qui sont locaux, pas les
objets qu'ils référencent. C'est particulièrement important à
comprendre pour les paramètres de fonction: si tu modifie (mutation)
un objet passé en paramètre, bien que le nom par lequel tu accèdes à
l'objet soit local, l'objet, lui, est bien celui qui a été passé à la
fonction.
Par contre, si tu rebinde un paramètre, ça n'affecte que
l'espace de nommage local. Exemple :
2) Avec *Python*, une variable est un simple nom faisant référence à un
objet (avec un type [taille + façon d'être interprété],
La notion de type est totalement différente.
Selon les catégories du C, il n'existe qu'un seul type en Python, le
type Py_Object_ptr, qui est un pointeur sur une structure de données
(je parle bien sûr de l'implémentation CPython - en Jython ou
IronPython, c'est probablement différent) (et bien sûr, je simplifie
outrageusement).
Selon la sémantique propre à Python, le 'type' d'un objet, c'est
l'objet class (int, dict, function, etc) qu'il référence via son
attribut __class__. A ce niveau, il n'y a pas de notion de 'taille',
de 'façon d'être interprété' ou autre. Il y a juste une référence sur
un autre objet dans lequel l'interpréteur ira chercher les attributs
non trouvés dans l'objet lui-même.
Par exemple avec ceci (en Python)
a=1
b=1
c=1
finalement, dans la mémoire se trouve un seul objet créé (l'entier 1).
Avec CPython, oui, mais parce que les petits entiers sont conservé en
cache.
Si tu remplace 1 par 33333, tu aura trois objets différents.
a = 333333
b = 333333
id(a)
135973460
id(b)
135973424
Par contre, si tu fais:
a = 33333
b = a
c = b
Tu aura bien trois noms référençant un seul et même objet.
Remarque en passant : Je me doutais bien que d'un langage à un autre,
des mêmes notions pouvaient avoir une implémentation différente. Mais
quand même, je n'imaginais pas que cela serait le cas pour la basique
notion de variable par exemple !
Attends de voir un langage fonctionnel pur (comme Haskell par
exemple) : tu ne peux tout simplement pas modifier la valeur d'une
variable une fois qu'elle est crée !-)
J'espère que d'un langage à un autre,
il ne faut pas tout réapprendre à chaque fois (car là, finalement, j'ai
du réapprendre ce qu'est une variable :-) ) ?
Non, la sémantique des variables de Python (de ce point de vue là) se
retrouve, à l'identique ou de façon très proche, dans pas mal d'autres
langages de haut niveau. De même que la sémantique des variables C se
retrouve dans pas mal de langages de bas niveau.
Ok, ok. Allez, quand même, en interne de chez interne (dans le code C de
CPython par exemple), il n'y a pas de pointeur qui traîne quelque part
dans la définition d'une variable Python ? Hein, pour me faire plaisir. :-)
Si, bien sûr. cf ci-dessus pour l'implémentation du type objet dans
CPython. A vrai dire, y a même tellement de pointeurs que tu ne sais
plus où donner de la tête. Content ?-)
En Python, tu n'a *que* des références sur des objets, *jamais* de
types 'immédiat' comme en C. Ne laisse pas la syntaxe te tromper, ce
n'est pas parce que tu définis un objet via une expression littérale
que tu a autre chose qu'une référence sur un objet.
Heu, un type immédiat c'est quoi ?
un entier en C.
On 9 avr, 01:12, Francois <mathsatta...@free.fr> wrote:
Ah oui, tiens, et les variables locales d'une fonctions ? C'est aussi un
nom associé à une référence sauf que l'espace des noms dans lequel elle
se trouve est dans un espace temporaire disjoint de l'espace de nom du
script principal ?
Exactement. Note bien que ce sont les *noms* qui sont locaux, pas les
objets qu'ils référencent. C'est particulièrement important à
comprendre pour les paramètres de fonction: si tu modifie (mutation)
un objet passé en paramètre, bien que le nom par lequel tu accèdes à
l'objet soit local, l'objet, lui, est bien celui qui a été passé à la
fonction.
Par contre, si tu rebinde un paramètre, ça n'affecte que
l'espace de nommage local. Exemple :
2) Avec *Python*, une variable est un simple nom faisant référence à un
objet (avec un type [taille + façon d'être interprété],
La notion de type est totalement différente.
Selon les catégories du C, il n'existe qu'un seul type en Python, le
type Py_Object_ptr, qui est un pointeur sur une structure de données
(je parle bien sûr de l'implémentation CPython - en Jython ou
IronPython, c'est probablement différent) (et bien sûr, je simplifie
outrageusement).
Selon la sémantique propre à Python, le 'type' d'un objet, c'est
l'objet class (int, dict, function, etc) qu'il référence via son
attribut __class__. A ce niveau, il n'y a pas de notion de 'taille',
de 'façon d'être interprété' ou autre. Il y a juste une référence sur
un autre objet dans lequel l'interpréteur ira chercher les attributs
non trouvés dans l'objet lui-même.
Par exemple avec ceci (en Python)
a=1
b=1
c=1
finalement, dans la mémoire se trouve un seul objet créé (l'entier 1).
Avec CPython, oui, mais parce que les petits entiers sont conservé en
cache.
Si tu remplace 1 par 33333, tu aura trois objets différents.
a = 333333
b = 333333
id(a)
135973460
id(b)
135973424
Par contre, si tu fais:
a = 33333
b = a
c = b
Tu aura bien trois noms référençant un seul et même objet.
Remarque en passant : Je me doutais bien que d'un langage à un autre,
des mêmes notions pouvaient avoir une implémentation différente. Mais
quand même, je n'imaginais pas que cela serait le cas pour la basique
notion de variable par exemple !
Attends de voir un langage fonctionnel pur (comme Haskell par
exemple) : tu ne peux tout simplement pas modifier la valeur d'une
variable une fois qu'elle est crée !-)
J'espère que d'un langage à un autre,
il ne faut pas tout réapprendre à chaque fois (car là, finalement, j'ai
du réapprendre ce qu'est une variable :-) ) ?
Non, la sémantique des variables de Python (de ce point de vue là) se
retrouve, à l'identique ou de façon très proche, dans pas mal d'autres
langages de haut niveau. De même que la sémantique des variables C se
retrouve dans pas mal de langages de bas niveau.
Ok, ok. Allez, quand même, en interne de chez interne (dans le code C de
CPython par exemple), il n'y a pas de pointeur qui traîne quelque part
dans la définition d'une variable Python ? Hein, pour me faire plaisir. :-)
Si, bien sûr. cf ci-dessus pour l'implémentation du type objet dans
CPython. A vrai dire, y a même tellement de pointeurs que tu ne sais
plus où donner de la tête. Content ?-)
En Python, tu n'a *que* des références sur des objets, *jamais* de
types 'immédiat' comme en C. Ne laisse pas la syntaxe te tromper, ce
n'est pas parce que tu définis un objet via une expression littérale
que tu a autre chose qu'une référence sur un objet.
Heu, un type immédiat c'est quoi ?
un entier en C.
On 9 avr, 01:12, Francois wrote:Ah oui, tiens, et les variables locales d'une fonctions ? C'est aussi un
nom associé à une référence sauf que l'espace des noms dans lequel elle
se trouve est dans un espace temporaire disjoint de l'espace de nom du
script principal ?
Exactement. Note bien que ce sont les *noms* qui sont locaux, pas les
objets qu'ils référencent. C'est particulièrement important à
comprendre pour les paramètres de fonction: si tu modifie (mutation)
un objet passé en paramètre, bien que le nom par lequel tu accèdes à
l'objet soit local, l'objet, lui, est bien celui qui a été passé à la
fonction.
Par contre, si tu rebinde un paramètre, ça n'affecte que
l'espace de nommage local. Exemple :
2) Avec *Python*, une variable est un simple nom faisant référence à un
objet (avec un type [taille + façon d'être interprété],
La notion de type est totalement différente.
Selon les catégories du C, il n'existe qu'un seul type en Python, le
type Py_Object_ptr, qui est un pointeur sur une structure de données
(je parle bien sûr de l'implémentation CPython - en Jython ou
IronPython, c'est probablement différent) (et bien sûr, je simplifie
outrageusement).
Selon la sémantique propre à Python, le 'type' d'un objet, c'est
l'objet class (int, dict, function, etc) qu'il référence via son
attribut __class__. A ce niveau, il n'y a pas de notion de 'taille',
de 'façon d'être interprété' ou autre. Il y a juste une référence sur
un autre objet dans lequel l'interpréteur ira chercher les attributs
non trouvés dans l'objet lui-même.
Par exemple avec ceci (en Python)
a=1
b=1
c=1
finalement, dans la mémoire se trouve un seul objet créé (l'entier 1).
Avec CPython, oui, mais parce que les petits entiers sont conservé en
cache.
Si tu remplace 1 par 33333, tu aura trois objets différents.
a = 333333
b = 333333
id(a)
135973460
id(b)
135973424
Par contre, si tu fais:
a = 33333
b = a
c = b
Tu aura bien trois noms référençant un seul et même objet.
Remarque en passant : Je me doutais bien que d'un langage à un autre,
des mêmes notions pouvaient avoir une implémentation différente. Mais
quand même, je n'imaginais pas que cela serait le cas pour la basique
notion de variable par exemple !
Attends de voir un langage fonctionnel pur (comme Haskell par
exemple) : tu ne peux tout simplement pas modifier la valeur d'une
variable une fois qu'elle est crée !-)
J'espère que d'un langage à un autre,
il ne faut pas tout réapprendre à chaque fois (car là, finalement, j'ai
du réapprendre ce qu'est une variable :-) ) ?
Non, la sémantique des variables de Python (de ce point de vue là) se
retrouve, à l'identique ou de façon très proche, dans pas mal d'autres
langages de haut niveau. De même que la sémantique des variables C se
retrouve dans pas mal de langages de bas niveau.
Ok, ok. Allez, quand même, en interne de chez interne (dans le code C de
CPython par exemple), il n'y a pas de pointeur qui traîne quelque part
dans la définition d'une variable Python ? Hein, pour me faire plaisir. :-)
Si, bien sûr. cf ci-dessus pour l'implémentation du type objet dans
CPython. A vrai dire, y a même tellement de pointeurs que tu ne sais
plus où donner de la tête. Content ?-)
En Python, tu n'a *que* des références sur des objets, *jamais* de
types 'immédiat' comme en C. Ne laisse pas la syntaxe te tromper, ce
n'est pas parce que tu définis un objet via une expression littérale
que tu a autre chose qu'une référence sur un objet.
Heu, un type immédiat c'est quoi ?
un entier en C.