accès aux groupes de discussion, consultation et publication d'articles, recherche de "newsgroups"...
membres, identifiez-vous
é-mail Mot de passe
nouveau ? mot de passe oublié ?
Chargement... Chargement en cours...

Groupes français belges canadiens suisses internationaux Nétiquette
Échangez opinions et commentaires dans les forums de discussion.

Re: Petites questions théoriques : peut-o n comparer une variable liste avec un point eur en C?

 [  Nouvelle Discussion Nouvelle discussion  |  Répondre au groupe Répondre au groupe  |  fr.comp.lang.python ] 

Retour : Accueil du site fr comp lang python   charte stats de ce groupe


  Sujet:   Re: Petites questions théoriques : peut-o n comparer une variable liste avec un point eur en C?  
 De: mathsatta...@free.fr (Francois)
 Groupes: fr.comp.lang.python
 Organisation: Guest of ProXad - France
 Date: 09. Apr 2008, 15:29:09
 References: 1 2 3 4 5
Bruno Desthuilliers a écrit :
> C'est le problème de la différence entre l'égalité (de valeur) et 
> l'identité. Selon les types, les deux peuvent être équivalents ou non.
> 
> Dis-toi bien que la grande majorité des objets sont 1/ mutables, et 2/ 
> avec un état beaucoup plus complexe qu'une simple valeur. La notion 
> d'égalité de valeur est arbitraire (en ce qu'elle est définie par le 
> type), celle d'identité ne l'est pas (deux objets sont identiques si 
> c'est le même objet, point, barre).
>
> [couic]
> 
> a = [1, 2, 3]
> b = [1, 2, 3]
> 
> A ce stade a et b sont égaux. Mais c'est accidentel. Doivent-ils être 
> identiques ? je peux vouloir modifier b sans modifier a
> 
> b[0] = 42
> 
> Si a et b avaient été identique, j'aurais, avec cette instruction, 
> modifié a également. Ainsi que toutes les autres listes de valeur 
> [1,2,3] existentes. Pas forcément ce que je voulais...

Ok. J'ai l'impression qu'en gros, il faut retenir ceci :

Avec

a = <truc>
b = <truc>

(où <truc> est un objet) dans la grande majorité des cas (pour la 
plupart des objets <truc>), a et b se réfèrent à des objets distincts. 
C'est par exemple toujours le cas quand <truc> est un objet mutable. 
Quand <truc> est un objet entier pas trop gros, où finalement seul sa 
valeur nous intéresse et qui n'est pas mutable, alors dans ce cas 
particulier a et b se réfèrent exactement au même objet qui se trouvera 
dans le «cache». Mais, finalement, ce cas particulier est un *détail*. 
Les raisons de ce détail, tu les as dites : un entier est non mutable 
donc on se moque éperdument de son identité, autant prendre la même 
quand l'entier est déjà créé avant. Quand l'entier est trop «gros», on 
retombe dans le cas général pour ne pas encombrer le «cache». Mais 
l'évolution du matériel tend à rendre la barre «entier trop gros» de 
plus en plus haute. Mais là, on est dans des considérations 
d'implémentation. Je m'arrête.

Est-ce correct ?

>>> 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 !-)
>>
>> On laissera ça pour ... une autre vie :-)
> 
> Pourquoi ? C'est intéressant aussi, comme approche, et il y a beaucoup à 
> en apprendre.

Tu as raisons. Je disais ça parce que j'étais un peu fatigué. :-)


>> Mais s'il y a *que* des références à des objets, cela veut dire que le 
>> simple entier "1" en Python est un réalité un objet plus complexe 
>> qu'un simple int ou char en C. Son codage binaire par exemple sera 
>> plus complexe que le naturel "00000001" ?
> 
> C'est rien de le dire. A ton avis, pourquoi on les mets en cache ?
> 
> Tiens, si tu veux en savoir plus, essaie ça dans ton shell Python:
> 
> a = 1
> for name in dir(a):
>     print name, " : ", getattr(a, name)

Je viens de le faire. Pfou !!! Effectivement, mon pauvre petit objet 1 
est une usine à gaz à lui tout seul !!! Ça c'est l'impression générale.

En revanche, j'avoue ne pas comprendre exactement le résultat de ce 
script. J'ai l'impression qu'en gros, on affiche tous les attributs de 
l'objet référencé par a (d'après ce que j'ai cru comprendre en me 
renseignant sur la fonction dir()). Pour moi, un attribut, c'est une 
variable interne à l'objet. Donc, on peut afficher la valeur de 
l'attribut en faisant a.attribut. Et bien, par exemple avec ceci :

 >>> a = 1 # avec dir(a) je vois par exemple qu'il y a l'attribut __add__
 >>> a.__add__
<method-wrapper '__add__' of int object at 0x816df38>

J'ai un résultat incompréhensible pour moi. C'est quoi ce résultat ? Ça 
ne ressemble ni à un entier, ni une séquence etc.


Une autre chose me taraude. En C, une variable admet un contenu ou 
valeur qui est codé(e) en binaire dans une zone contiguë de la mémoire. 
En Python, cela a-t-il un sens de parler de contenu / valeur d'un objet 
? J'en arrive à me dire que non.
- J'ai l'impression qu'on peut à la limite parler de contenu : un objet 
dans la mémoire doit bien être stocké quelque part. En plus j'ai 
l'impression que le stockage se fait dans des zones qui ne sont même pas 
forcément contiguës.
- Mais je me demande si ça a toujours un sens de parler de valeur d'un 
objet.

Par exemple, en C, je m'étais «amusé» à faire un tout petit programme 
qui affiche le code binaire du contenu d'une variable. Est-ce possible 
de faire la même chose en Python, c'est-à-dire afficher le code binaire 
que contient un objet ? (si la question à un sens en Python)


-- 
François


PS : À un moment du parlais de "OP". Ça veut dire quoi ?


DateSujet  Auteur
01.01.
o 
Groups Explorer contact votre avis comment ça marche? rechercher un groupe suggérer un groupe abuse accueil du site   Imprimer cette page   Envoyer cette page à un(e) ami(e)