Discussion :

[jingenbl]

Comment comprendre la diff�rence entre ceci

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
#-*- coding: iso-8859-15 -*-
 
class personne:
    def __init__(self,nom):
        self.nom=nom
        self.dico={}
        self.dico['cree']=nom
    def fiche(self):
        print ('mon nom est: %s et d=%s') % (self.nom,self.dico)
e={}
 
e[0]=personne('alice')
e[0].dico['zero']='zero'
e[0].fiche()
e[1]=personne('bernard')
e[1].dico['un']='un'
e[1].fiche()
e[0].fiche()

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
mon nom est: alice et d={'zero': 'zero', 'cree': 'alice'}
mon nom est: bernard et d={'un': 'un', 'cree': 'bernard'}
mon nom est: alice et d={'zero': 'zero', 'cree': 'alice'}

qui donne bien un dico par personne et cela

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
#-*- coding: iso-8859-15 -*-
 
class personne:
    nom=''
    dico={}
    def __init__(self,nom):
        self.nom=nom
        self.dico['cree']=nom
    def fiche(self):
        print ('mon nom est: %s et d=%s') % (self.nom,self.dico)
e={}
 
e[0]=personne('alice')
e[0].dico['zero']='zero'
e[0].fiche()
e[1]=personne('bernard')
e[1].dico['un']='un'
e[1].fiche()
e[0].fiche()

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
mon nom est: alice et d={'zero': 'zero', 'cree': 'alice'}
mon nom est: bernard et d={'zero': 'zero', 'un': 'un', 'cree': 'bernard'}
mon nom est: alice et d={'zero': 'zero', 'un': 'un', 'cree': 'bernard'}

qui cr�e un dico commun pour les personnes et un nom diff�rent?

Merci d'apporter de la lumi�re � ma compr�hension du fonctionnement de Python

[plxpy]

Houl� : ton exemple est bien compliqu� !

Plus simplement :

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
26
27
28
>>> class Classe(object):
...     c = 0
...
>>> Classe.c
0
>>> 
>>> Classe.__dict__
dict_proxy({'__dict__': <attribute '__dict__' of 'Classe' objects>, '__module__': '__main__', '__weakref__': <attribute '__weakref__' of 'Classe' objects>, 'c': 0, '__doc__': None})
>>>
>>> obj1 = Classe()
>>> obj2 = Classe()
>>> 
>>> obj1.__dict__
{}
>>> 
>>> obj1.c = "je la joue perso"
>>> 
>>> obj1.__dict__
{'c': 'je la joue perso'}
>>> 
>>> obj1.c
'je la joue perso'
>>> Classe.c
0
>>> obj2.c
0
>>> obj2.__dict__
{}

c est, � la base, un attribut de classe, commun � toutes les instances. On ne le retrouve pas dans les attributs propres � une instance (lignes 13 et 14), seulement dans les attributs de la classe (lignes 7 et 8).

Si une instance d�cide de se particulariser et de la "jouer perso", un attribut qui lui est propre est cr�� (lignes 16 � 19). Les autres instances n'auront toujours pas d'attribut "c" propre (lignes 25 � 28).

Je n'ai pas (re)trouv� dans la doc officielle ce "truc". Mais, pour faire court, "c'est comme �a", faut faire avec.

[jingenbl]

Merci pour la r�ponse.
C'est limpide, je comprends...

Bonnes f�tes!

[plxpy]

Avec plaisir. Bonnes f�tes � toi aussi !

[PauseKawa]

Bonjour,

Je n'ai pas (re)trouv� dans la doc officielle ce "truc". Mais, pour faire court, "c'est comme �a", faut faire avec.

C'est vrais qu'une explication manque sur le fonctionnement interne de la machine.

Le comportement �tant trop proche des param�tres par d�faut pour les fonctions il m'est difficile de ne pas faire le parall�le.
Pour rappel sur les param�tres par d�faut, la doc officielle �tant succincte (The default values are evaluated at the point of function definition in the defining scope).

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
>>> def f(l=[]):
...     l.append(0)
...     return l
... 
>>> f()
[0]
>>> f()
[0, 0]
>>> f()
[0, 0, 0]
>>> id(f())
3074972876L
>>> id(f())
3074972876L
>>> id(f())
3074972876L
>>> f()
[0, 0, 0, 0, 0, 0, 0]

Nous avons bien ici le m�me objet (la fonction f, id 3074972876L), l'utilisation de la m�thode se fait donc sur la m�me liste.

Pour les instances cela vas de m�me

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
>>> class Foo:
...     value = 0
... 
>>> f = Foo()
>>> f.__class__
<class __main__.Foo at 0xb7745c8c>
>>> f1 = Foo()
>>> f1.__class__
<class __main__.Foo at 0xb7745c8c>

On utilise donc bien le m�me objet bien que les instances soit diff�rentes.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
>>> f
<__main__.Foo instance at 0xb7485e8c>
>>> f1
<__main__.Foo instance at 0xb7485c6c>

Pour ce qui est de 'la jouer perso' la r�solution de l'attribut commence par l'espace de nom de l'instance.

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
>>> class Foo(object):
...     classattr = "class"
... 
>>> f = Foo()
>>> f.classattr
'class'
>>> id(f.classattr)
3077724160L
>>> f.__class__.classattr
'class'
>>> id(f.__class__.classattr)
3077724160L
>>> f.classattr = "instance"
>>> f.__dict__
{'classattr': 'instance'}
>>> f.classattr
'instance'
>>> id(f.classattr)
3077621664L
>>> f.__class__.classattr
'class'
>>> id(f.__class__.classattr)
3077724160L

L'attribut cr�� est donc bien propre � l'instance.

@+ et bonnes f�tes

[fred1599]

On utilise donc bien le m�me objet bien que les instances soit diff�rentes.

Je dirais plut�t que les instances sont les objets, et qu'ils diff�rent (heureusement). Les classes sont les patrons de ces objets et il est normal que eux ne diff�rent pas...

[PauseKawa]

Les classes aussi sont des objets, au sens interpr�tation du code.

When a class definition is entered, a new namespace is created, and used as the local scope � thus, all assignments to local variables go into this new namespace. In particular, function definitions bind the name of the new function here.

When a class definition is left normally (via the end), a class object is created. This is basically a wrapper around the contents of the namespace created by the class definition; we�ll learn more about class objects in the next section. The original local scope (the one in effect just before the class definition was entered) is reinstated, and the class object is bound here to the class name given in the class definition header (ClassName in the example).

Dans ce sens tout ce qui est dit plus haut explique que cela n'est qu'un parcours des espaces de noms, l'objet classe ayant le siens qui est cr�� lors de la lecture du code.

[fred1599]

Ok, on s'est mal compris, je parlais dans un sens concret du probl�me et non de la syntaxe.

[PauseKawa]

Bonjour,

Les classes sont les patrons de ces objets et il est normal que eux ne diff�rent pas...

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
>>> class Foo:
...     classattr = 0
...     def changeattr(self, newattr):
...          self.__class__.classattr = newattr
... 
>>> f = Foo()
>>> f.classattr
0
>>> f.changeattr(1)
>>> f.classattr
1
>>> f1 = Foo()
>>> f1.classattr
1

Cela reste un namespace et Python reste tr�s dynamique... (et je ne parle pas des mutables)

@+

[fred1599]

Les classes sont les patrons de ces objets et il est normal que eux ne diff�rent pas

Ce que je veux dire, c'est que l'on peut modifier un dessin technique (une classe) parce-qu'on a fait un oubli ou fait une erreur, il en reste pas moins que la classe une fois cr��e permet la construction de diff�rents objets (instances) et cette classe ne changera pas, on partira toujours du m�me dessin technique pour la construction.

Si on veut changer le comportement de cette classe, on utilisera l'h�ritage...

Si on veut cr�er/modifier dynamiquement une classe, on parlera de metaclass, mais...

Metaclasses are deeper magic than 99% of users should ever worry about. If you wonder whether you need them, you don't (the people who actually need them know with certainty that they need them, and don't need an explanation about why).

�a reste des cas tr�s sp�cifiques.

[PauseKawa]

�a reste des cas tr�s sp�cifiques.

Oui...

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
class Storage(object):
    _singleton = None
    datas = []
    def __new__(cls, *args, **kwargs):
        if not cls._singleton:
            cls._singleton = super(Storage, cls).__new__(cls, *args, **kwargs)
        return cls._singleton
    def add(self, newdata):
        self.datas.append(newdata)
    def getdata(self):
        return self.datas
    # ...
 
 
s = Storage()
s.add(1)
s1 = Storage()
print(s1.getdata())
print(id(s) == id(s1))
print(s is s1)

Mais l� c'est plus que du hors sujet (et turbocapillotract� comme dirait quelqu�un)

@+

[fred1599]

Oui, oui mais quand tu modifieras s1, tu modifieras s, ce qui signifie qu'il n'y a en fait qu'une seule instance, mais j'ai toujours eu du mal � voir l'int�r�t du singleton que je trouve contre intuitif au principe de base de la classe qui est :
Une classe permet la construction de plusieurs objets (instances)

Je n'en perd pas moins qu'il peut �tre utile, cependant l'inconv�nient est de laisser la possibilit� de cr�er une autre instance, trompeur pour l'utilisateur de cette classe, il pourrait croire utiliser un autre objet (diff�rent) alors que ce n'est pas le cas. Il est pr�f�rable de lui interdire l'instanciation (le principe du singleton).

[PauseKawa]

L'exemple du singleton (toujours aussi controvers� comme pattern ) n'est l� que pour l'utilisation de _singleton.

Il est pr�f�rable de lui interdire l'instanciation (le principe du singleton).

C'est ce qui est fait dans la PEP318

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
def singleton(cls):
    instances = {}
    def getinstance():
        if cls not in instances:
            instances[cls] = cls()
        return instances[cls]
    return getinstance
 
@singleton
class MyClass:
    ...

[wiztricks]

Oui, oui mais quand tu modifieras s1, tu modifieras s, ce qui signifie qu'il n'y a en fait qu'une seule instance, mais j'ai toujours eu du mal � voir l'int�r�t du singleton que je trouve contre intuitif au principe de base de la classe qui est :
Une classe permet la construction de plusieurs objets (instances).

Une classe permet de fabriquer une collection d'objets semblables.
Une collection peut �tre vide, r�duite � N �l�ments, permettre la cr�ation d'un nombre ind�fini d'�l�ments diff�rents (au sens "is").

singleton, monostate, Borg permettent de traduire ces diff�rentes propri�t�s.
Ce sont des patterns de "design".
Coder ces propri�t�s sera plus ou moins ardu suivant le langage.
Il ne sera pas toujours utile ni n�cessaire qu'il y ait bijection entre collection au sens "design" et sa r�alisation en code.

c'est que l'on peut modifier un dessin technique (une classe) parce-qu'on a fait un oubli ou fait une erreur, il en reste pas moins que la classe une fois cr��e permet la construction de diff�rents objets (instances) et cette classe ne changera pas, on partira toujours du m�me dessin technique pour la construction.

Supposons que l'objet soit une "chaise".
Un caillou, un tabouret,... quoi que ce soit pourvu qu'on puisse poser ses fesses dessus fera l'affaire. Il y a pleins de fa�ons pour fabriquer un objet utilisable en tant que chaise.
En Python, on appelle cela "duck typing".

Hmm, bonnes f�tes!
- W