Premiers pas sous Python

Version imprimable

27/08/2010, 16h15
.Nawak

Premiers pas sous Python

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 ?
27/08/2010, 17h39
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 !
28/08/2010, 00h39
.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...)
28/08/2010, 01h01
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)
28/08/2010, 08h49
kango
Citation:

Envoyé par .Nawak

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:

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.
28/08/2010, 09h44
Sve@r
Citation:

Envoyé par .Nawak

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 ???

Citation:

Envoyé par .Nawak

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) ???
Citation:
Envoyé par kango

quand on écrit:

Code:

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
>>>
28/08/2010, 10h20
kango

Citation:

Envoyé par Sve@r

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 :)
28/08/2010, 10h27
fred1599
Code:

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

b est exactement le même objet que a

kango a raison ;)
28/08/2010, 14h35
Sve@r
Citation:
Envoyé par fred1599

Code:

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

Citation:

Envoyé par kango

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) :ccool:
28/08/2010, 14h43
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::ccool:

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.
28/08/2010, 14h46
Sve@r

Citation:

Envoyé par Luke spywoker

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...
28/08/2010, 18h56
.Nawak

Merci pour tout ces renseignements.

Citation:

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 ?
28/08/2010, 22h26
Sve@r

Citation:

Envoyé par .Nawak

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.

Citation:

Envoyé par .Nawak

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...
28/08/2010, 22h41
.Nawak

Merci pour l'explication.
;)

Citation:

Envoyé par Sve@r

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:

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.

Citation:
Envoyé par dividee
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:

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:

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)...

29/08/2010, 18h35
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:

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:

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:

print b # affiche 1

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

1 2 a = [] b = a
Les deux noms a et b pointent vers le même objet (une liste).

Si on fait:

Code:

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:

print b # affiche [1]
29/08/2010, 18h51
fred1599

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

Citation:

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

Mais aussi:

Citation:

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

Un peu de lecture:

source
30/08/2010, 00h50
dividee

Citation:

Envoyé par Sve@r

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".

Citation:

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:

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:

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.
30/08/2010, 02h04
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.

Citation:

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.

Citation:

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:

Citation:

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:

Citation:

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 :

Citation:

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:

Citation:

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:

Citation:

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

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

Mais la phrase juste après:

Citation:

Every variable is created with an initial value.

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

Puis:

Citation:

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.

Citation:

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:

Citation:

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:

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:

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:

1 2 3 4 a = 2 print id(a) a += 3 print id(a)
donne
Code:

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.

@dividee

Citation:

Envoyé par dividee

@kango:
écrire

Code:

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:

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.

oui je suis entièrement d'accord avec ça, l'opération d'affectation crée un nouvel objet en mémoire (sauf dans le cas des singleton) mon exemple était mal choisi, j'aurais dû mettre a += 1.

@eyquem:

Citation:

Et j’attends de voir un code avec définition de __iadd__ qui va donner la même adresse.

Je pense que dividee faisait allusion à mon message:

Code:

a = a + 1

créera automatiquement un nouvel objet en mémoire, et ce quelque soit le type de a (muable ou non muable).

en revanche:

Code:

a += 1

ne crée un nouvel objet en mémoire que si a est non muable (un entier par exemple). C'est donc précisemment cet exemple que j'aurais dû fournir (pour mettre en relation la modification 'in-place' d'un type muable et d'un type non-muable).

En effet, pour un muable (une liste) c'est la même zone mémoire qui continue d'être utilisée:
Code:

1 2 3 4 5 6 7 8 9 10 11 >>> a = [] >>> id(a) 140076096098176 >>> a += [1] >>> a [1] >>> id(a) 140076096098176 >>> a = a + [2] >>> id(a) 140076096259496
Donc dividee a raison dans le sens ou la distinction entre type muable et non muable n'opére que lors d'une opération sur un objet mais pas à l'affectation (opérateur =). Dans ce dernier cas, seul le cas du singleton sera différent. Et ceci se mêle à ce que fait Python pour limiter la création d'objet en mémoire, ainsi, sur ma version de Python (2.6.4 64bits sur Ubuntu 9.04 64bits):
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 >>> c = 1 >>> d = 1 >>> c is d True #c'est Python qui décide !, l'affectation d = 1 ne crée pas un nouvel objet en mémoire. #mais cela peut être différent avec d'autres versions (ou implémentation ?) de Python. >>> a = None >>> b = None >>> a is b True #ça se sera toujours le cas puisque None est un singleton (il n'existe qu'un seul et #unique objet de ce type au cours de l'exécution du programme). Les singleton ne se #limitent pas à None, on peut créer les nôtres :). >>> e = [] >>> f = [] >>> e is f False #ça sera toujours le cas aussi car les listes sont muables :)
Oala, je pense qu'à la nomenclature près on est d'accords sur la mécanique sous-jacente :). Comme eyquem, je ne suis pas fan de la dénomination 'variable' je trouve qu'elle a tendance à apporter confusion pour des gens venant d'autres langages, c'est pour cela que j'ai appelé ça "nom" ou "étiquette" mais si "étiquette" est peut être plus parlant, il ne trouve pas d'échos dans les documentations officielles, "nom" en revanche pourrait coller.

30/08/2010, 08h55
.Nawak

Citation:

eyquem wrote : "À partir de là, tout devient simple (...)"

A ce moment de la lecture, je n'ai su que faire : rire nerveusement ou pleurer ?

Imaginez la scène : [un oeil à demi fermé, la paupière palpitante, une veine gonflée sur le front, de la bave à la commissure des lèvres, des tremblements incontrôlés]

La réponse doit être 42. Non ?
;)

Sinon, heureusement que j'ai fait le choix d'un langage clair. Faut pas demander le reste si déjà ils n'arrivent pas à "nommer" les choses, à leur donner une signification propre qui n'admette aucun contresens. Bon, avec l'exposé de eyquem, je pense avoir saisi le truc sur a et b.

Ce sont des conteneurs, tous. Ensuite, ce qu'on met dedans peu importe, mais pour être concret :

conteneur A = fruits
conteneur B = conteneur A
conteneur A = légumes

On dit :
- mettons des fruits dans le conteneur A
- mettons le même type de fruits dans le conteneur B
- remplaçons les fruits du conteneur A par des légumes

Du coup, le conteneur B contient toujours des fruits.

J'espère que c'est ça, sinon j'ai rien capté, ce qui m'inquiète pour la suite.
;)
30/08/2010, 10h36
kango

ne t'en fais pas, tu n'as pas besoin de saisir la substantifique moelle de tout ça de suite :) c'est un détail de l'implémentation du langage qui ne sert qu'à avoir une compréhension "fine" de ce qui se passe.

cette abstraction, aussi complexe parait elle, est justement là pour faciliter bien des choses (tu n'auras pas à "jouer" avec des pointeurs en Python par exemple) dans certains cas bien précis, ne pas la comprendre, peut être source de confusion. Mais en fait tout est d'une implacable logique. C'est comme les pointeurs, au début on ne comprend pas mais dès qu'on a saisi, tout s'éclaire et devient logique. Dans les langages utilisant massivement ces pointeurs, on n'a pas le choix de comprendre la mécanique complexe, en Python, on a le choix.

ce sujet est le plus complexe à assimiler, tout le reste, coule de source :)

Citation:

Envoyé par .Nawak

A ce moment de la lecture, je n'ai su que faire : rire nerveusement ou pleurer ?

Imaginez la scène : [un oeil à demi fermé, la paupière palpitante, une veine gonflée sur le front, de la bave à la commissure des lèvres, des tremblements incontrôlés]

La réponse doit être 42. Non ?
;)

T'inquiète pas. Je fais du Python depuis 3 ans et j'ai eu du mal à tout lire. Mais c'est un superbe exposé. Peut-être un poil trop "académique" mais chapeau à eyquem qui a eu le courage et la force d'écrire tout ça.

Citation:

Envoyé par .Nawak

Ce sont des conteneurs, tous. Ensuite, ce qu'on met dedans peu importe, mais pour être concret :

conteneur A = fruits
conteneur B = conteneur A
conteneur A = légumes

On dit :
- mettons des fruits dans le conteneur A
- mettons le même type de fruits dans le conteneur B
- remplaçons les fruits du conteneur A par des légumes

Du coup, le conteneur B contient toujours des fruits.

J'espère que c'est ça, sinon j'ai rien capté, ce qui m'inquiète pour la suite.
;)

Non pas "peu importe". Cela dépend de ce que tu y mets.

Je vais essayer de t'aider à comprendre mais ce sera avec des mots à moi. Pas forcément les bon termes pour le puriste mais j'espère qui t'aideront à mieux saisir les problèmes possibles de ce superbe langage et la façon de les éviter...

Dans Python, tu as d'abord la possibilité de mémoriser des trucs simples. Des nombres entiers ou flottants. C'est suffisant pour celui qui utilise Python pour compter ses slips et ses chaussettes et leur prix individuel
Exemple
Code:

1 2 3 4 5 6 7 >>> a=5 >>> b=a >>> a 5 >>> b 5 >>>
Dans ce cas, tu as le droit de "considérer" que les deux identificateurs "a" et "b" sont indépendants. Que ce soit vrai ou pas à ce niveau importe peu. De toute façon, si tu commences à travailler comme si c'était vrai, alors Python s'arrangera pour que ça le soit
Exemple
Code:

1 2 3 4 5 6 >>> a+=1 >>> a 6 >>> b 5 >>>
Et donc maintenant tu vois bien que les deux identificateurs ont chacun leur vie à vivre. Et que ce fut vrai ou pas juste avant importe peu pour le programmeur qui s'en sert pour compter ses noix.

Ensuite, tu as possibilité de stocker des éléments plus complexes comme les listes ou les dictionnaires (on reste toutefois dans le cadre d'éléments modifiables)
Exemple
Code:

1 2 3 4 5 6 7 >>> a=range(5) >>> b=a >>> a [0, 1, 2, 3, 4] >>> b [0, 1, 2, 3, 4] >>>
Dans ce cas, tu n'as pas le droit de considérer que t'as deux listes distinctes. En fait, tu n'en as qu'une seule en mémoire et les deux identificateurs "a" et "b" identifient la même liste. Et donc modifier un des éléments influera sur l'autre
Exemple
Code:

1 2 3 4 5 6 7 >>> a[2]='f' >>> b[3]='g' >>> a [0, 1, 'f', 'g', 4] >>> b [0, 1, 'f', 'g', 4] >>>
Une fois que tu gardes ça en tête, tu n'as plus de problème de programmation. Et bien entendu, dans le cas où t'aurais besoin d'obtenir une réelle copie de "a", tu as des outils qui te permettent de spécifier ce besoin
Exemple
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 >>> a=range(5) >>> b=list(a) >>> c=[x for x in a] >>> a[2]='f' >>> b[3]='g' >>> c[4]='h' >>> a [0, 1, 'f', 3, 4] >>> b [0, 1, 2, 'g', 4] >>> c [0, 1, 2, 3, 'h'] >>>
Enfin il y a les objets non modifiables, comme les strings ou les tuples. Dans ce cas, comme tu ne peux pas les modifier, le problème de savoir si deux identificateurs identifient le même objet ou pas importe peu. Tu t'en sers et puis c'est tout.

PS:

Attention toutefois à pas pousser mémé dans les orties quand on s'amuse avec les identificateurs car sinon, on peut en baver pour démêler la pelote
Exemple
Code:

1 2 3 4 5 6 7 8 9 10 11 >>> a=range(5) >>> a[2]=a >>> a [0, 1, [...], 3, 4] >>> a[2] [0, 1, [...], 3, 4] >>> a[2][2] [0, 1, [...], 3, 4] >>> a[2][2][2] [0, 1, [...], 3, 4] >>> # Je crois qu'on peut aller très loin...

Sve@r, ton dernier exemple me fait penser à une sympathique implémentation pour un buffer circulaire:

Code:

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
26
27
28
class FullBufferError(Exception): pass
class EmptyBufferError(Exception): pass
 
class CircularBuffer(object):
    def __init__(self, size):
        self._begin = [None]
        cur = self._begin
        for _ in xrange(size):
            cur.append([None])
            cur = cur[1]
        cur.append(self._begin)
        self._end = self._begin
 
    def add(self, value):
        if self._end[1] is self._begin:
            raise FullBufferError()
        self._end[0] = value
        self._end = self._end[1]
 
    def pop(self):
        if self._begin is self._end:
            raise EmptyBufferError()
        value, self._begin = self._begin
        return value
 
    def __del__(self):
        # casse la circularité
        self._end[1] = None

Code:

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
26
27
28
29
30
>>> c = CircularBuffer(2)
>>> c.add(1)
>>> c.add(2)
>>> c.add(3)
Traceback (most recent call last):
  File "<interactive input>", line 1, in <module>
  File "C:\Prog\python\Script1.py", line 16, in add
    raise FullBufferError()
FullBufferError
>>> c.pop()
1
>>> c.add(3)
>>> c._begin
[2, [3, [1, [...]]]]
>>> c._end
[1, [2, [3, [...]]]]
>>> c.pop()
2
>>> c.pop()
3
>>> c.pop()
Traceback (most recent call last):
  File "<interactive input>", line 1, in <module>
  File "C:\Prog\python\Script1.py", line 22, in pop
    raise EmptyBufferError()
EmptyBufferError
>>> c._begin
[1, [2, [3, [...]]]]
>>> c._end
[1, [2, [3, [...]]]]

C'est un bon exercice pour comprendre les références...

08/09/2010, 21h52
_Serge_

Bonjour,
Je débute en programmation et je tente de m'intéresser à Python.
Il y a quelques années, j'ai bien touché un peu à l'assembleur sur mon Oric1, puis Atmos et après, mon 520 modifié au fer à soudé en 1040STF. En ce temps là, c'était beaucoup plus simple. ;)
Aussi, je vous prie d'être indulgent si je raconte des co..eries.
Pour esayer de synthétiser ce que j'ai compris de la magistrale explication de Equyem.
Les identifiants (A,x,y...) sont en fait un peu comme les tags de Firefox (j'aime bien Firefox aussi :mrgreen:)
On colle une, ou plusieurs étiquettes sur l'enveloppe qui contient l'adresse de la boîte qui contient l'objet/l'enveloppe qui contient les adresses des objets. Pour ce dernier point, il s'agit d'une supposition de ma part.
Ainsi, si on colle notre étiquette sur une autre enveloppe, on est forcément dirigé sur une autre boîte qui ne peut contenir le même objet que précédemment. Sauf si cet objet a été détruit/retiré puis recréé/remis dans la nouvelle boite entre temps (s'il a déménagé, quoi).
En fait, on prend une enveloppe A6 et on écrit une adresse dessus pour que le facteur fasse son boulot.
Bon, c'est très imagé. :oops:
09/09/2010, 00h00
dividee

Euh...

Citation:

Envoyé par _Serge_

On colle une, ou plusieurs étiquettes sur l'enveloppe qui contient l'adresse de la boîte qui contient l'objet/l'enveloppe qui contient les adresses des objets.

L'étiquette, c'est une métaphore pour quoi ? Le nom de la variable ?
Et d'habitude, on écrit une adresse sur une enveloppe, pas dedans...

Citation:

Ainsi, si on colle notre étiquette sur une autre enveloppe, on est forcément dirigé sur une autre boîte qui ne peut contenir le même objet que précédemment. Sauf si cet objet a été détruit/retiré puis recréé/remis dans la nouvelle boite entre temps (s'il a déménagé, quoi).

Là je suis complètement perdu 8O

Citation:

En fait, on prend une enveloppe A6 et on écrit une adresse dessus pour que le facteur fasse son boulot.

:fou:

Je vais essayer une autre métaphore, disons un tableau blanc. Cela représente la mémoire de l'ordinateur. Ou plutôt la partie accessible au process Python.

Sur ce tableau, vous pouvez afficher des avis (ce sont les objets) qui sont maintenus par un où plusieurs magnets, sur lesquels on colle un étiquette (ce sont les variables, sur l'étiquette il y a le nom de la variable). On pourrait aussi utiliser des punaises, mais c'est moins bien, ça fait des trous dans les objets :roll:

Déposer un magnet sur un avis, c'est l'opération d'assignation. On peut mettre plusieurs magnets sur un même avis, c'est la métaphore de ce qu'on appelle "l'aliasing", avoir plusieurs noms pour un objet. Mais si on retire le dernier magnet, l'avis tombe dans la poubelle qui se trouve en-dessous (l'objet est détruit, le compteur de référence arrive à 0).

Là où ça se complique, c'est qu'un objet contient des attributs, qui sont en quelque sorte des variables attachées à cet objet. C'est un peu comme si, sur un avis, on avait sur la face arrière des petits magnets attachés dans le papier qui peuvent servir à faire tenir d'autres avis en-dessous. Mais, et c'est là que la métaphore se casse la gueule, qui ne seraient pas suffisants à faire tenir l'avis qui les contient en place s'il n'y a pas un magnet qui le tient en place par au-dessus :koi: Mais admettons cette incongruité de la physique pythonienne.

On peut donc imaginer un tableau rempli d'avis mais maintenus par un seul magnet sur l'avis qui est au-dessus de tous les autres. Si on enlève ce magnet-là, toute la structure se casse la gueule récursivement.

Maintenant, les références circulaires: on peut imaginer trois avis, A, B et C, qui disposent chacun d'un magnet en-dessous, et qui se recouvrent partiellement, de sorte que A maintienne B, B maintienne C et C maintienne A. Bingo, ça tient en place tout seul vu que chaque avis est maintenu par un magnet au-dessus de lui. On peut même y arriver avec 2 avis, si rien ne les oblige à avoir une forme rectangulaire. S'il n'y a pas de magnet étiqueté dessus, on ne peut plus y accéder (pour y accéder on doit pouvoir les nommer, soit directement grâce aux étiquettes sur les magnets ("l'avis sous le magnet étiquetté A", soit indirectement "l'avis sous le second magnet de l'avis sous le magnet étiquetté B"). Dans ce cas, ces objets en références circulaires utilisent de la place sur le tableau pour rien. Le seul capable de les enlever, c'est votre collègue GC, qui passe de temps en temps, quand il veut bien et qu'il n'est pas en congé-maladie, pour retirer ces saletés du tableau.

Bon je m'emballe un peu :P
Les métaphores imagées, c'est fun mais je suis pas sûr que ça aide beaucoup à la compréhension ;)
09/09/2010, 08h32
Sve@r

Citation:

Envoyé par dividee

Les métaphores imagées, c'est fun mais je suis pas sûr que ça aide beaucoup à la compréhension ;)

Mouais. :ccool::ccool::ccool:

Désolé __Serge__, essaye plutôt de lire mon explication avec des exemples concrets, je pense sincèrement qu'elle est plus simple et te permettra de te lancer dans Python sans te faire des noeuds au cerveau. Ou mieux, télécharge le superbe tuto de Swinnen et lis le tranquillement en tapant les exemples qui s'y trouvent...
09/09/2010, 20h41
_Serge_

Ouais, faut bien rigoler un peu.
Bon, le coup des magnets n'est pas forcément judicieux puisque d'après ce que j'ai compris on ne peut pas les coller directement sur les avis. Les magnets sont simplement collés ailleurs sur le tableau, sur un avis qui indique l'emplacement de l'objet sur le tableau blanc ou des autres avis qui indiquent...
L'avantage c'est que lorsque le dernier magnet d'un avis est retiré, on est pas obligé de nettoyer le tableau pour retirer l'objet qui ne sert plus (sinon on passerait son temps à nettoyer) simplement lorsque l'on pose un nouvel avis, on s'assure de mettre un nouvel objet à la place du vieux.

:mouarf: OK, je sors.;)
26/09/2010, 12h27
.Nawak

Re,

Bon, le bouquin n'est pas adapté à ma vision des choses. Beaucoup trop de verbiage, et peu d'exemples réellement utiles en production. J'aurais aimé voir plus de choses sur la manipulation des chaînes, et une organisation plus pragmatique. On sent que l'auteur est un professeur à l'ancienne, le Maître devant ses élèves, et cela se révèle assez lourd au final. Bref, l'approche du bouquin me déçoit fortement.

Du coup, je recherche un autre bouquin, plus proches de mes aspirations. Lorsque je jouais un peu avec ActionScript (Flash), j'avais acheté :
- Actionscript la référence
- Actionscript en action
Qui étaient de très bons bouquins. Le premier était une référence du langage, avec chaque mot, sa description, son usage, ses paramètres, et un exemple pratique. Le second s'attardait sur des exemples concrets, en expliquant pourquoi il était plus intelligent de procéder de telle ou telle manière (ex : manipuler un fichier XML et arranger les chaînes à sa guise, faire une pause dans un programme en attente d'un évènement, etc.).

Est-ce que cela existe ?
Je pense fortement à acheter "Dive into Python", qui m'a l'air bien plus "carré".
Dive into Python 3: Amazon.fr: Mark Pilgrim: Livres en anglais@@AMEPARAM@@http://ecx.images-amazon.com/images/I/51WqvTbtj3L.@@AMEPARAM@@51WqvTbtj3L

Sinon, je me suis trouvé un projet pour apprendre. Pour le boulot, je reçois mes plannings de RV clients par internet. Seulement, la mise en page est déplorable concernant l'impression. Hors, dernièrement, les dev. nous ont pondu un flux XML (mal fichu, mais bon...).

Je compte donc tenter un script qui :
- ouvre une connexion openvpn avec le certificat adéquat
- récupère le fichier XML et le copie dans un fichier local de travail
- nettoie le bordel (faut voir l'organisation des données "à l'arrache").
- conserve les éléments utiles
- sort un fichier texte prêt à imprimer

Et ce n'est pas avec le bouquin que j'ai acheté que je m'en sortirais. Il manque la blinde de références et d'exemples orientés "métier" (franchement, faire 2 tanks qui se tirent dessus... non, mais plutôt que d'apprendre à parser un fichier XML ou nettoyer des chaînes de caractères...).

Si vous avez des indications ou pistes pour orienter mes recherches, je vous en remercie par avance.
26/09/2010, 17h37
dividee

Le livre de Swinnen est destiné aux débutants en programmation; c'est un livre pour apprendre les bases de la programmation, comme son titre l'indique, python étant un moyen au service de ce but. Mais ce n'est visiblement pas ce qu'il te faut.

"Dive into Python" te conviendra sans doute mieux, effectivement. Je suppose que tu as vu qu'il était lui aussi disponible en ligne ? (http://diveintopython3.org/). Même si tu préfères la version papier, cela permet de le feuilleter tranquillement pour voir s'il te convient.

Cela dit, la bibliothèque standard de python est tellement étendue, sans même parler des bibliothèques tierces, qu'aucun livre ne pourrait tout couvrir. A un moment, il faut bien se contenter de la documentation des librairies. La facilité qu'on a à expérimenter interactivement est aussi une bénédiction.
26/09/2010, 21h12
.Nawak

Citation:

Le livre de Swinnen est destiné aux débutants en programmation; c'est un livre pour apprendre les bases de la programmation.

Je t'assure être novice en programmation, et ce n'est pas avec ce livre seul qu'on peut avoir des bases solides. Autant les premiers chapitres sont intéressants, autant dès qu'il attaque TKinter, ça devient vite pénible. Quant à la POO, je n'ai fait que survoler, vu les exemples peu inspirés, à mille lieux d'une utilisation courante.

Citation:

(...) Mais ce n'est visiblement pas ce qu'il te faut.

Je confirme.

A priori, je préfère un dico se concentrant sur l'essentiel du langage, sans rentrer dans les exceptions et menus détails. Quelques exemples pratiques, concrets, montrant du code utile en production et réutilisable. Jouer ensuite aux Lego™(©), brique après brique, quitte à faire des erreurs et à recommencer. Là, avec ce bouquin, j'ai bien quelques éléments de réponse sur la manière d'ouvrir et d'écrire dans un fichier, sur quelques manipulations possibles sur les chaînes, mais ça manque de matière.

Autrement, je préfère une bonne vieille lecture papier qu'un PDF, pas toujours très pratique.
;)
27/09/2010, 21h55
Sve@r

Citation:

Envoyé par .Nawak

Autrement, je préfère une bonne vieille lecture papier qu'un PDF, pas toujours très pratique.;)

Ouch pauvres arbres :calim2::calim2::calim2:
(moi aussi j'ai imprimé le swinnen);)