Discussion :

[.Nawak]

Bonjour,

Passionné d'informatique au sens large, je suis un généraliste : j'ai travaillé en infographie, je me suis intéressé aux standards du web, et je bosse actuellement comme technicien dans les réseaux et télécommunications. Lors de mes études, j'ai eu l'occasion de toucher à Flash ActionScript (proche du Javascript), au shell Linux Bash, bref, des "petits" langages interprétés. Toujours du structuré, je n'ai jamais osé l'orienté objet. Je me suis rendu compte que me casser la tête sur un problème, chercher une alternative, une solution de contournement, et obtenir un résultat efficace me plaisait. Je n'en ferais pas mon travail, mais de temps à autres, par passion, lorsque j'aurais besoin d'un outil à ma convenance, j'apprécierais réellement savoir programmer, ou au moins comprendre comment tel ou tel code fonctionne pour obtenir tel résultat.

J'ai donc lu de nombreux avis et points de vue sur le net, et j'ai essayé de restreindre mes choix à un langage qui pourrait me correspondre. J'ai une préférence pour les interprétés, sur lesquels ont peu avoir un aperçu direct du résultat sans avoir à compiler, qu'il soit ouvert, avec une écriture claire, agréable à apprendre. C'est pourquoi je me suis naturellement orienté vers Python.

J'en ai donc profité pour acheter le livre suivant :
[ame="http://www.amazon.fr/Apprendre-programmer-avec-Python-dexercices/dp/2212127081/ref=sr_1_1?ie=UTF8&s=books&qid=1282917600&sr=8-1"]Apprendre à programmer avec Python 3 : Avec plus de 50 pages de corigés d'exercices !: Amazon.fr: Gérard Swinnen: Livres@@AMEPARAM@@http://ecx.images-amazon.com/images/I/512T2XYZbLL.@@AMEPARAM@@512T2XYZbLL[/ame]

Un bouquin, c'est bien pour débuter. Mais l'expérience de professionnels, c'est mieux. J'aurais donc besoin de vos conseils pour bien commencer sur le langage Python (gardez à l'esprit que je commencerais directement sur la 3.x) :
- quelles sont les points essentiels sur lesquels m'attarder ?
- quelles sont les "pièges" à éviter ? à quoi dois-je faire attention ?
- d'autres livres intéressants ? d'autres ressources utiles ?
- des conseils divers ? (ce qu'il vous semble utile de préciser)

Last but not least; j'ai pu remarquer que pour progresser, le mieux est de se fixer un objectif et travailler en groupe, par émulation de chacun de ses membres. A votre connaissance, existe-t-il des "clubs" de développeurs Python ?

[kango]

bonjour et bienvenue surtout

des points essentiels sur lesquels s'attarder ? il y en a plusieurs et je ne connais pas le bouquin dont tu parles (même si j'ai vaguement parcouru celui sur la version précédente, du même auteur). je dirais donc: multiplier les sources de documentation: lire des tutos sur le oueb, utiliser 2 ou 3 bouquins différents. Pourquoi ? parce que chaque auteur a sa propre sensibilité, son propre style, sa propre pédagogie, son lot de prérequis. Tu seras par exemple plus sensible à la pédagogie d'un auteur qu'un autre pour diverses raisons qui font que moi j'aime certain type de livre, de style et de ton et que toi tu aimes des styles différents.

Par exemple les livres de référence sont plus difficile pour commencer mais deviennent plus vite incontournable dés que l'on gagne en expérience. Des livres plutôt accès apprentissage (certains nécessitent tout de même d'avoir des connaissance en programmation) sont plus utiles dans les premiers mois.

Les pièges a éviter: le système de référence de Python me semble être le principal. C'est pas vraiment un piège, disons que c'est une difficulté (parce que c'est un particularisme du langage Python) sur laquelle les débutants butent souvent.

Des clubs de développeurs je ne sais pas vraiment. Tu trouveras sur ce site parfois quelques challenges (il y en a un en ce moment relatif au développement de jeux).

Mais il y en a d'autres aussi, comme le Projet Euler si tu aimes les maths (http://projecteuler.net/) ou alors le Python Challenge (http://www.pythonchallenge.com/). Ce dernier j'accroche pas trop personnellement, je trouve que c'est un peu trop tiré par les cheveux parfois leur énigme (je fais allusion à celle du Peak Hell pour ceux qui ont essayé, voir à celle de la fermeture éclair) pour des non anglophones...

Ensuite, il y a des projets open source qui cherchent des contributeurs Il faut déjà s'être un peu fait les dents avec Python cependant et trouver un projet qui te motive. Et puis, qui sait, peut être que tu pourras même contribuer au projet python lui même

Enfin et pour conclure, le forum ici c'est bien aussi (sans oublier la faq, les exemples de source) pour échanger et poser des questions. Y a des gens compétents et disponibles. Et autre point fort de la communauté ici, on trouve des interlocuteurs pour tout un tas de sujets relatifs à Python, aussi bien les IHM, les librairies scientifiques, des férus d'algo, de techno web et réseau, de base de données, de conception en général. tu les reconnaîtras ;p

Oala, bon pythonage !

[.Nawak]

Hé bien, merci de l'accueil.

Lorsque j'avais touché à ActionScript, je m'étais rendu compte que je n'aimais pas les bouquins "pas à pas", et j'étais fan des références, reprenant le vocabulaire propre au langage en expliquant succinctement son utilisation, avec un exemple. Beaucoup plus utile que "faites ci, faites ça", selon moi.

Qu'appelles-tu le système de référence ? (je vais aller sur la FAQ de ce pas...)

[Jannus]

Tu peux aussi consulter les nombreuses ressources Developpez.com : Forum Python F.A.Q Python Tutoriels Python Sources Python Outils Python Livres Python (voir le menu en haut dela page)

[kango]

Qu'appelles-tu le système de référence ? (je vais aller sur la FAQ de ce pas...)

salut,

il n'y a pas d'article relatif à ça dans la fac. le système de références est ce qui permet à Python de se passer des pointeurs.

les transmissions d'arguments à des fonctions se font par référence, là où en c/c++ ils se font par valeur par défaut.

quand on écrit:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
a = 1
b = a

b est exactement le même objet que a (même adresse mémoire) comme si on avait utilisé un pointeur.

[Sve@r]

J'en ai donc profité pour acheter le livre suivant :
Apprendre à programmer avec Python 3 : Avec plus de 50 pages de corigés d'exercices !: Amazon.fr: Gérard Swinnen: Livres

Tu sais que son auteur l'offre gratuitement en téléchargement format PDF ???

Un bouquin, c'est bien pour débuter. Mais l'expérience de professionnels, c'est mieux. J'aurais donc besoin de vos conseils pour bien commencer sur le langage Python (gardez à l'esprit que je commencerais directement sur la 3.x) :
- quelles sont les points essentiels sur lesquels m'attarder ?
- quelles sont les "pièges" à éviter ? à quoi dois-je faire attention ?
- d'autres livres intéressants ? d'autres ressources utiles ?
- des conseils divers ? (ce qu'il vous semble utile de préciser)

Perso, j'ai commencé Python il y a 3 ans et j'ai commencé avec le même livre que toi que j'ai téléchargé, imprimé et lu. Bon j'ai sauté certaines parties qui s'attardent sur le principe d'une boucle ou le fonctionnement de turtle mais dans l'ensemble, je pense qu'on ne peut pas commencer un langage sans lire attentivement un tuto approprié. Et celui-là est superbement fait !!!
Ensuite c'est ta propre expérience qui te fera aller vers les points essentiels. Toutefois, je te recommande aussi "dive into python" http://diveintopython3.org qui approfondira certains points utiles. Et as-tu vu que sur ce site "developpez" il y a des tutos Python (tout en haut de la page) ???

quand on écrit:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
a = 1
b = a

b est exactement le même objet que a (même adresse mémoire) comme si on avait utilisé un pointeur.

Ptet en Python 3 que je ne connais pas (je suis resté à la 2.5) mais pas en v2
IDLE 1.2.4
>>> a=1
>>> b=a
>>> a=2
>>> b
1
>>>

[kango]

a=1
b=a
a=2
b
>>>1

oui, mais tu remarqueras que je n'ai pas modifié a
tu introduis ici la deuxième difficulté: la différence entre les types muables et les types non muables

[fred1599]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
>>> a=2
>>> b=a
>>> id(a); id(b)
3144884
3144884

b est exactement le même objet que a

kango a raison

[Sve@r]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
>>> a=2
>>> b=a
>>> id(a); id(b)
3144884
3144884

kango a raison

Exact. Même résultat avec Python 2.5

oui, mais tu remarqueras que je n'ai pas modifié a
tu introduis ici la deuxième difficulté: la différence entre les types muables et les types non muables

Argh, comme la mécanique quantique. C'est vrai jusqu'à ce qu'on regarde et quand on regarde, là ça n'est plus vrai !!!

Joli. J'aurais jamais pensé que a et b associaient le même objet uniquement jusqu'à ce qu'on modifie l'un ou l'autre. Merci à vous deux de ces exemples qui m'ont éclairé (surtout en passant par id)

[Luke spywoker]

Voici des liens menant a des documents de références crue et complet que je préfère également aux tutoriels éducatifs mais par lesquelles il faut quand meme passer:

la doc officiel de Python 3.0.1: http://docs.python.org/release/3.0.1/download.html

la doc officiel de Python 3.1.2: http://docs.python.org/release/3.1.2/download.html



Je ne veux interferer avec ton future choix d'interface graphique mais j'ai le meme style de documentation(Crue, en anglais & en francais)pour Tkinter.

[Sve@r]

Je ne veux interferer avec ton future choix d'interface graphique mais j'ai le meme style de documentation(Crue, en anglais & en francais)pour Tkinter.

Arf, moi je ne jure que par Qt. Toutefois je ne sais pas si cette librairie a été portée sous Python 3...

[.Nawak]

Merci pour tout ces renseignements.

Tu sais que son auteur l'offre gratuitement en téléchargement format PDF ?

Oui, mais je préfère lire un livre classique correctement imprimé qu'un PDF en lecture horizontale. Des bouquins d'informatique, je n'en achète pas souvent, alors autant faire l'effort financier pour récompenser l'auteur.


Concernant l'exemple sur a et b, lorsqu'on assigne une valeur à une variable "a", et qu'on assigne cette même variable à "b", alors "b" prend la valeur de "a". Seulement, si on change la valeur de "a" par la suite, "b" conserve la valeur qui lui avait été assignée initialement. C'est l'idée ?

[Sve@r]

Oui, mais je préfère lire un livre classique correctement imprimé qu'un PDF en lecture horizontale. Des bouquins d'informatique, je n'en achète pas souvent, alors autant faire l'effort financier pour récompenser l'auteur.

Oui, bel état d'esprit. Surtout qu'il mérite.

Concernant l'exemple sur a et b, lorsqu'on assigne une valeur à une variable "a", et qu'on assigne cette même variable à "b", alors "b" prend la valeur de "a". Seulement, si on change la valeur de "a" par la suite, "b" conserve la valeur qui lui avait été assignée initialement. C'est l'idée ?

Non. Ca c'est un comportement de langages plus anciens style C ou Pascal ou Basic. Deux variables de noms distincts donc deux zones mémoires distinctes.
Ici, le comportement qui est décrit, c'est que a et b, parce qu'ils ont la même valeur, n'occupent alors qu'une seule zone mémoire. En fait, a et b sont la même variable (économie de mémoire).
Ensuite, si on modifie l'une des deux, alors seulement à ce moment là le moteur Python fera l'effort d'assigner une zone pour a et une autre pour b...

[.Nawak]

Merci pour l'explication.

[dividee]

Ici, le comportement qui est décrit, c'est que a et b, parce qu'ils ont la même valeur, n'occupent alors qu'une seule zone mémoire. En fait, a et b sont la même variable (économie de mémoire).
Ensuite, si on modifie l'une des deux, alors seulement à ce moment là le moteur Python fera l'effort d'assigner une zone pour a et une autre pour b...

Je ne suis pas d'accord. a et b sont deux variables distinctes qui référencent le même objet. Chacune a sa zone mémoire, celle-ci contient une référence à l'objet. Il faut imaginer les références comme des pointeurs améliorés:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
a = 1
 
  |---|            |---|
a | --+----------> | 1 |
  |---|            |---|
 
b = a
 
  |---|            |---|
a | --+----------> | 1 |
  |---|      |---> |---|
             |
  |---|      |      
b | --+------/  
  |---|           
 
a = 2
 
  |---|            |---|
a | --+----------> | 1 |
  |---|            |---|
 
  |---|            |---|
b | --+----------> | 2 |
  |---|            |---|

Cela n'a rien à voir avec le fait que l'objet soit mutable ou pas.
Il ne faut pas confondre la création d'objet avec la création de variable/référence.

[Sve@r]

Je ne suis pas d'accord. a et b sont deux variables distinctes qui référencent le même objet. Chacune a sa zone mémoire, celle-ci contient une référence à l'objet. Il faut imaginer les références comme des pointeurs améliorés:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
a = 1
 
  |---|            |---|
a | --+----------> | 1 |
  |---|            |---|
 
b = a
 
  |---|            |---|
a | --+----------> | 1 |
  |---|      |---> |---|
             |
  |---|      |      
b | --+------/  
  |---|           
 
a = 2
 
  |---|            |---|
a | --+----------> | 1 |
  |---|            |---|
 
  |---|            |---|
b | --+----------> | 2 |
  |---|            |---|

Cela n'a rien à voir avec le fait que l'objet soit mutable ou pas.
Il ne faut pas confondre la création d'objet avec la création de variable/référence.

Jolis dessins. Tu as dû en baver pour les faire.

Mais bon, quand tu demandes l'identifiant de a et de b tu obtiens la même valeur. Alors que la réalité soit illustrée par ton schéma ou bien par celui-là plus simpliste

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
a = 1
 
  |---|
a | 1 |
  |---|
 
b = a
 
  |---|
a | 1 | b
  |---|

Quelle importance ? Si tous les outils de tracking, de débugging ou autres ne montrent pas de différence entre a et b, alors utilisons le principe du rasoir d'Occam (privilégier l'hypothèse la moins compliquée)...

[kango]

hehe comme quoi, quand je dis que c'est un piège pour les débutants

je partage la vision de dividee, avec:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
a = 1
b = a

a et b sont 2 "noms" ou deux "étiquettes" référençant le même objet (l'entier 1).

Un entier étant non mutable, sa valeur ne peut pas changer, du coup une opération comme:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

a = a + 1

crée un nouvel objet en mémoire (un entier 2) et le "nom" ou l'"étiquette" a lui est maintenant associée. En revanche, le "nom" b pointe toujours sur le vieil objet (l'entier 1) du coup:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

print b # affiche 1

En prenant le même exemple avec un type muable, une liste par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
a = []
b = a

Les deux noms a et b pointent vers le même objet (une liste).

Si on fait:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

a.append(1) #on modifie la liste en lui ajoutant une valeur

le nom a continue de référencer la même objet en mémoire. et du coup l'association de b n'est pas perdue:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

print b # affiche [1]

[fred1599]

Je suis d'accord avec dividee, les variables sont des simples étiquettes où l'on affecte un objet.

In Python, every variable is a simple reference to an underlying object.

Mais aussi:

A Python variable is little more than a name which refers to an object.

Un peu de lecture:

source

[dividee]

Mais bon, quand tu demandes l'identifiant de a et de b tu obtiens la même valeur.

La fonction id renvoie l'identité de l'objet référencé par a ou b. a et b sont des identifiants. L' "identifiant de a" je ne comprends pas ce que cela veut dire. L' "identité de a", c'est en fait un abus de langage communément utilisé pour l' "identité de l'objet référencé par a".

Quelle importance ? Si tous les outils de tracking, de débugging ou autres ne montrent pas de différence entre a et b, alors utilisons le principe du rasoir d'Occam (privilégier l'hypothèse la moins compliquée)...

D'accord, cette représentation simplifiée convient pour un exemple simple comme celui-ci, mais quand tu as, par exemple, deux listes (ou n'importe quel type d'objet composite) qui partagent une partie de leurs éléments, cela n'est pas représentable avec ta notation simplifiée, et tu dois à ce moment faire l'effort d'étendre la notation en y représentant le concept de référence, si tu veux avoir une vision correcte des choses. Et représenter certaines références mais pas toutes (càd ne pas représenter celles qui possèdent un nom dans ton programme) me semble compliquer le modèle plus que le simplifier.

@kango:
écrire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

a = a + b

créera toujours un nouvel objet, que a soit mutable ou non. Enfin, le programmeur qui définit la méthode __add__ de la classe fait ce qu'il veut, mais l'implémenter d'une façon qui modifie a serait une aberration, en contradiction totale avec la sémantique de l'addition.

Par contre pour

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 a += b

cela va dépendre. L'objet référencé par a ne sera modifié que si la méthode __iadd__ est définie dans la classe de a pour effectuer l'opération en place.

[eyquem]

Si vous consentiez à vous rendre compte un jour que les zônes mémoires porteuses de données en Python (je parle des données auxquelles on s’intéresse dans un programme, celles qu’on manipule, celles qu’on soumet à des calculs et des transformations) ne sont pas des variables, et que vous vous décidiez à ne plus employer ce terme impropre et confusionnant, ça irait bien mieux.

Le problème, c’est quand on emploie des mots sans y attacher une signification précise et rigoureusement fixe.

Il faut donc commencer par mettre les choses au clair sur ce point.

Voici la vison des choses à laquelle je suis parvenu à force de creuser le problème. Je ne prétends pas qu’elle soit parfaite.







Une variable, c’est une case mémoire dans la RAM avec un contenu: la valeur de ce contenu peut changer sans que l’adresse de la variable change; une variable a une localisation fixe et une valeur modifiable.
En PHP, C++, Java, il y a des variables.





En Python, les porteurs de données sont des objets.

Objects are Python abstraction for data. All data in a Python program is represented by objects or by relations between objects

http://docs.python.org/reference/dat...lues-and-types

En Python, tout est donc objet. Mais je ne sais pas pourquoi la doc appelle ça des abstractions, pour moi un objet est un agrégat de bits de structure et de valeurs telles qu’il représente conventionnellement une donnée selon un ensemble de règles. C’est donc quelque chose de très concret qui existe physiquement en mémoire.

Cela s’appelle un objet, avec la même signification du mot objet en Python que dans les autres langages parce que tout objet Python est instance d’une classe définie par l’utilisateur ou instance d’un type.







Le truc important c’est qu’un objet Python est traité d’une façon particulière par Python.

Every object has an identity, a type and a value.

An object’s identity never changes once it has been created; you may think of it as the object’s address in memory. The ‘is‘ operator compares the identity of two objects; the id() function returns an integer representing its identity (currently implemented as its address).

An object’s type is also unchangeable. (...)

The value of some objects can change. Objects whose value can change are said to be mutable; objects whose value is unchangeable once they are created are called immutable. (...)

http://docs.python.org/reference/dat...lues-and-types

Les objets mutables sont des objets tels que listes, dictionnaires, etc, c’est à dire des objets composites formés d’objets simples de base.

Ce sont les objets simples qui sont immutables et ce sont eux qui, de par leurs caractères, font le particularisme de Python comme disait kango:
étant à la fois fixes et non mutables, ils ne peuvent constituer le support de ce qu’on appelle une “variable“ en mathématique = quelque chose susceptible de prendre plusieurs valeurs successivement.

Ce qui fait que le “data model“ de Python se débrouille donc autrement pour mimer les variables mathématiques.
Ce qui fait aussi que je ne suis pas tellement d’accord avec dividee sur un point: le “data model“ de Python a bien un certain rapport avec l’origine de la distinction mutable/immutable.
D’ailleurs, voir aussi la citation à la fin.






Ensuite il faut débroussailler un point.

Quand on écrit A = 1 , la lettre A n’est pas l’objet. Rigoureusement parlant, c’est l’identifiant de l’objet.

Pour l’interpréteur Python qui lit A = 1, le A est le symbole de l’objet, c’est à dire ce qui va lui permettre de trouver l’objet dans la RAM.

Pour un mental humain qui lit A= 1 : « A prend la valeur 1» , il emploie, lui, un terme (A) pour autre chose que ce qu’est strictement A (une lettre): il fait une métonymie.
Et si en plus il dit «la variable A prend la valeur 1», il double la métonymie par une inexactitude.
Il devrait dire: « on crée un objet d'identifiant A »








Bon, mais alors, quand on écrit A = 1, cela veut dire quoi plus précisément et concrétement ?

Eh bien à mon avis, la remarque suivante est pleine de justesse:

Merci à vous deux de ces exemples qui m'ont éclairé (surtout en passant par id)

C’est en effet seulement en s’appuyant sur ce que donne id() qu’on finit par arriver à comprendre comment tout ça fonctionne.

Car si A= 1 crée un objet 1 qui est repéré par l’identifiant A, d’après la doc, id(A) est l’adresse de l’objet A.

Peut on imaginer que juste aprés l’instruction A = 1, l’interpréteur ne connaisse pas encore l’adresse de A ?
Non. Car si on lui demande print id(A) juste après A = 1, et en admettant qu’il pourrait déterminer l’adresse de l’objet à partir de l’objet lui même, comment ferait il pour trouver d’abord l’objet ?
Il faut bien que la valeur id(A) existe quelque part , juste aprés A = 1 et que ce quelque part ne soit pas dans l’objet A, car l’existence d’une adresse dans un objet que l’interpréteur ne saurait pas trouver, ça servirait à quoi ?

Donc logiquement, et bien que je n’ai jamais rien lu de très précis sur ce point, l’adresse d’un objet A, juste après l’instruction A = 1, doit bien exister et se trouver ailleurs que dans l’objet.
Et vu que les valeurs renvoyées par id(X) sont différentes au gré des assignations successives d’un identifiant X, il faut conclure que l’adresse atteinte par un id(x) est ..... une variable.
C’est nécessairement une variable puisque son contenu peut changer.
À mon avis, les entités qui hébergent les adresses des objets sont les seules entités dans un programme qui soient de véritables variables et non pas des objets.





Donc quand on écrit A = 1, cela crée un objet A et une variable “adrA“ contenant l’adresse de A .

D’ailleurs soit dit en passant, si quelqu’un sait comment arriver à obtenir un identifiant IDI tel que print IDI donne l’adresse d’un objet A contenue dans une variable “adrA“ , j’aimerais bien savoir comment on fait.
Car personnellement je n’y suis pas arrivé. Il faut toujours faire id(A) , id() étant une fonction, pour obtenir l'adresse de A. Cette particularité prouve que ce qui héberge les adresses des objets est de nature particulière.

C’est pourquoi j’ai écrit "adrA" , c’est pour signifier que je ne considère pas "adrA" comme l’identifiant de l'objet en question. Mais comme il faut bien la nommer, je mets des “ “

Enfin bref.....





D’une certaine façon, A repère donc bien une variable mais de façon directe: cette variable est “adrA“ .

Par contre, ce à quoi on pense quand on parle de A par métonymie, c’est en fait à l’objet d'identifiant A , qui est repéré indirectement et n’est pas une variable.

Ça c’est le “data model“ de Python.




L’ “execution model“ de Python, quant à lui, fait que lorsque l’interpréteur rencontre des identifiants X, il sait qu’il doit prendre/manipuler la valeur de l’objet d’identifiant X et non pas celle de la variable “adrX“ , mais c’est bien cette dernière qui lui permet d’atteindre l’objet d’identifiant X.

Une variable “adrX“ contient de l’information. Mais ce n’est généralement pas cette information qui nous intéresse, c’est la valeur représentés par les objets. La preuve que ce que je dis là n’est pas fumeux:

In most cases, when we talk about the value of a container, we imply the values, not the identities of the contained objects;

http://docs.python.org/reference/dat...lues-and-types

C’est pour ça qu’au début , j’ai parlé des données auxquelles on s’intéresse et qu’on manipule dans un programme: je désignais là les valeurs représentées par les objets , pas les infos contenues dans les variables d’adresse.





-----------------------------------------------


À partir de là, tout devient simple:



A = 1
l’allocation d’une zône mémoire a lieu, dédiée à constituer l’objet "entier de valeur 1".
Une variable “adrA“ contenant l’adresse de cette zône mémoire est créée, et cette variable-adresse est liée à l’identifiant A au sein de l’espace de noms adéquat, ce qui constitue l'aspect assignation.
A repère dès lors directement “adrA“ et indirectement l’objet “entier de valeur 1“
Je pense que c'est ainsi qu'est en fait concrètement obtenu le “binding“ d’un objet et de son identifiant.


B = A
une autre variable “adrB“ est créée , elle prend la même valeur que “adrA“ : les identifiants A et B repèrent (indirectement) le même objet 1


A = 2
une autre allocation de mémoire est faite, quelque part ailleurs dans la mémoire, pour permettre la représentation de l’objet “entier de valeur 2“, , puisque un objet simple tel que l'entier 1 ne peut pas changer de valeur; la variable “adrA“ prend une nouvelle valeur, celle de l’adresse de l’objet 2.
La variable “adrB“ reste avec sa valeur adresse de l’objet 1. Ce dernier continue d’exister puisqu’il est repéré par un identifiant.





Les variables “adrA“ et “adrB“ agissent donc bien comme des pointeurs, comme il a été dit. Je ne vois juste pas en quoi ils sont des pointeurs améliorés.


Il doit bien y avoir allocation de mémoire aussi pour créer ces sortes de pointeurs, mais on conçoit que ces cases mémoires là sont plus simples à structurer que celles dédiées à la représentation des objets puisque les variables “adrX“ ne contiennent toujours qu’un seul et même type, fort simple, de valeur: un entier constituant une adresse.

Mais en C++ , un pointeur est une variable qui pointe vers une autre variable.
Or ce n’est pas le cas en Python où les “adrX“ ne pointent pas vers des variables mais vers des objets qui, lorsqu’ils sont simples, sont non modifiables.

Je suppose que c’est pour cette raison qu' en Python les variables “adrX“ ne sont pas appelées de pointeurs, mais des références.



Cependant en C++, une référence est un machin qui pointe comme un pointeur vers une variable mais ce n’est pas un pointeur, parce que la valeur du machin ne peut pas changer.
En Java, ces références sont appelées "handle".

On peut cependant trouver une logique commune en ce sens que le mot “référence“ se rapporte dans les deux cas à quelque chose dans lequel est impliquée une stabilité:

• en C++ ce qui est pointé est une variable et la référence est stable
  
• en Python, l'objet pointé est stable et c’est la référence qui est variable.

On me dira que le schéma que je propose n’est apparemment pas toujours vérifié si on se réfère à la citation suivante :

Types affect almost all aspects of object behavior. Even the importance of object identity is affected in some sense: for immutable types, operations that compute new values may actually return a reference to any existing object with the same type and value, while for mutable objects this is not allowed. E.g., after a = 1; b = 1, a and b may or may not refer to the same object with the value one, depending on the implementation, but after c = []; d = [], c and d are guaranteed to refer to two different, unique, newly created empty lists. (Note that c = d = [] assigns the same object to both c and d.)

http://docs.python.org/reference/dat...lues-and-types

Mais il s’agit là de a = 1 puis b = 1
et non pas de a = 1 puis b = a.





-------------------------------------------------



La métaphore de l’étiquette ou d’un petit drapeau est pas mal: elle a un aspect visuel qui rend moins abstraite la réflexion, je trouve qu’elle fonctionne bien.

Mais il faut se garder à mon avis de la présenter tout de suite à des débutants, avant d’avoir expliqué la vraie réalité sous jacente sans approximation.

En effet, l’idée de l’étiquette, c’est, me semble-t-il, que sur l’étiquette est écrit toujours le même nom (identifiant) mais qu’elle se détache et se rattache ailleurs. Or c’est le contraire en réalité: une variable “adrX“ a une localisation fixe et c’est la valeur écrite dessus qui change.




-------------------------------------


Le lien que tu donnes, fred1599, a l’air a priori pas mal. C’est toujours intéressant d’avoir différentes manières de traiter un sujet.
Mais je n’aime pas du tout son flou terminologique.
Le texte fait succéder sans vergogne:

Variables hold the state of our program. (...) in The Assignment Statement we’ll cover the basic assignment statement for changing the value of a variable. (...) The state of our program as a whole is the state of all of the program’s variables. When one variable changes, the overall state has changed.

Quelque chose qui “holds“ un état et qui change, ça ne peut pas être une lettre - identifiant.
Donc ici, variable = case mémoire qui contient une valeur changeante



Et tout de suite après:

Variables are the names your program assigns to the results of an expression.

Là , variable = nom (= l’identifiant)



Mais la phrase juste après:

Every variable is created with an initial value.

Paf , ça redevient la variable - case mémoire.



Puis:

Variables will change to identify new objects and the objects identified by a variable can change their internal state.

Tout change; qu’est ce que ça peut bien vouloir dire ?
Un objet qui change son état interne, ça ne peut être qu’un objet composite mutable. Cette affirmation n’a absolument pas une portée générale.

A Python variable name must be at least one letter,

Cette fois, le mot “variable“ ne suffit pas pour désigner un identifiant. Le texte avoue là que la signification du mot “variable“ est imprécise et fluctuante et que pour être sûr d’être compris dans cette phrase, il faut ajouter un mot.



Dans la suite du texte, on sent que “variable“ a surtout la signification d’identifiant. Mais au détour d’une phrase, la notion de case mémoire repointe le bout du nez:

if an object is not saved in a variable,

Je trouve pénible ce genre de textes dans lesquels tout se mélange.



PS:

Je sais bien que partout dans la doc officielle de Python, le terme “variable“ est employé alors que j'estime que ça va mieux quand on s’en interdit l’emploi.

1- le terme est partout utilisé comme signifiant “le nom d’un objet“ c’est à dire son identifiant (indirect) et l’on ne peut douter que les rédacteurs des docs savent à quoi s’en tenir sur le data model et l’execution model que le terme “variable“ recouvre de façon implicite. Une fois qu’on a bien compris ce qui se passe sous le capot, on peut se permettre d’appeler les choses comme on veut, du moment que le vrai sens est implicitement connu et toujours cohérent

2- d’une certaine façon, c’est vrai qu’un identifiant repère une variable puisque, de mon point de vue, il repère directement la variable “adrX“



-------------


Soit dit en passant, une telle attraction de la signification du mot “variable“ vers la notion d’identifiant est dûe à l’influence des mathématiques, dans lesquelles il n’y a pas la notion de contenant hébergeant des valeurs:
une variable mathématique Y représente à la fois virtuellement toutes les valeurs possibles d’un ensemble désigné, et une valeur précise à un moment donné. Zavonen nous dira si je ne raconte pas trop de betise.

Se laisser contaminer par cette influence, c’est le signe qu’on n’est pas assez proche du niveau de l’implémentation concrète.



C’est la même attraction mathématique qui fait s’étonner de:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
a=1
b=a
a=2
print b

écrit 1
parce que ça veut dire qu’on lit b=a comme : b et a deviennent identiques.

Or il me semble que dans les langages à variables, b=a se lit: la variable b prend la valeur qui se trouve déjà dans la variable a. Et non pas: la variable a et la variable b deviennent la même. Et que dans ce cadre, les instructions ci-dessus ne devraient pas poser de problème. C’est d’ailleurs la saine réaction de .Nawak dans le message #12:
pourquoi donc trouver anormal que des variables distinctes a et b aient des valeurs qui évoluent indépendamment ?

À moins d’être déjà contaminé par le fait qu’en Python b = a signifie "l’objet b est le même que a" mais qu’on reste en même temps sur l’idée que b et a sont des variables ? ?

C’est bizarre.







–-----------------------------------------------



Tout ce laïus montre que je partage fortement l’avis de kango:
la connaissance du sytème de repérage des objets par références de Python est le point fondamental à bien saisir, même si on peut coder très longtemps en Python avant d’être confronté à son importance.

Cette connaissance est indispensable pour éviter les pièges posés lors de la copie de certains objets (listes...) et pour bien saisir ce qu’il se passe quand on définit des arguments par défaut pour une fonction.



Le second sujet de grande importance est à mon avis la compréhension du système des espaces de noms. Il faut comprendre qu’un espace de nom est implémenté comme un dictionnaire, et il faut comprendre comment ces dictionnaires fonctionnent.



Liées à ce sujet, il y a les notions de portées et de blocs.


Avoir les idées dégrossies sur ces points, c’est déjà bien à mon avis.





Mon conseil: dans un premier temps, lire attentivement et souvent:


http://docs.python.org/reference/datamodel.html
3.1 Objects, values and types

http://docs.python.org/reference/executionmodel.html
4.1 Naming and binding

http://docs.python.org/tutorial/classes.html
9.1 A Word about Names and Objects
9.2 Python Scopes and Namespaces





EDIT :


Je viens de voir avec plaisir le dernier post de dividee. On considère tous les deux que a et b sont des identifiants et qu’il faut dire (rigoureusement, mais parfois on est elliptique): l’objet d’identifiant a, l’objet d’identifant b , pour désigner les objets, a et b n’étant que des noms.
Ce qui me conforte dans ma vison des choses.



Par contre je ne suis pas d’accord pour

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
a = 2
a += 1

L’objet 2 ne peut pas être modifié en place, c’est un objet immutable.

Ce que je constate:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
a = 2
print id(a)
a += 3
print id(a)

donne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
8776460
8776424

Et j’attends de voir un code avec définition de __iadd__ qui va donner la même adresse.
Je suis prêt à parier que je me trompe, puisque c’est dividee qui le dit.