Discussion :

[nikopol82]

Bonjour,
Le pattern N.V.I., pour "non virtual interface" a été proposé par Herb Sutter dans son article "Virtuality, C/C++ Users Journal, 19(3), 2001" disponible ici:

http://www.gotw.ca/publications/mill18.htm

En résumé, il recommande, (quand on développe en C++) de rendre les fonctions virtuelles privées, et d'écrire une interface publique non virtuelle. Pour plus de détails sur ce pattern, je vous invite à lire l'article.

Utilisateur de python depuis peu, j'ai par réflexe appliqué les même recettes, considérée comme des bonnes pratiques dans mon langage de référence. Seulement le comportement qui en résulte n'est pas celui que j'attendais. En effet, si on considère l'exemple suivant:

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
class A:
    def foo(self):
        self.__foo_impl_private();
        self._foo_impl_protected();
 
    def __foo_impl_private(self):
        pass;
 
    def _foo_impl_protected(self):
        pass
 
class B(A):
    def __foo_impl_private(self):
        print 'coin'
 
    def _foo_impl_protected(self):
        print 'coin coin'
 
if __name__ == "__main__":
    x = B()
    x.foo()

A l'éxécution, ce code imprime

Code :

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

coin coin

là ou je m'attendais à

Code :

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

1
2
coin
coin coin

On peut en déduire que le fait que __foo_impl_private soit privée empêche la classe de base d'appeler l'implémentation de la classe dérivée.

Quelqu'un peut-il m'éclairer sur ce comportement ? Il semble que l'idée préconçue selon laquelle les méthodes de classes en python se comportent comme des méthodes virtuelles en C++ soit erronée.

[shadowsam]

Salut,

Ton problème vient du fait que tu utilises le "__" comme préfixe pour ta méthode privée. En effet, dans ce cas, python remplace "__methodname" par "__classname_methodname". Je t'invite a lire la doc ICI.

Ton code devient donc 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
19
20
21
22
 
class A:
    def foo(self):
        self.__A_foo_impl_private();
        self._foo_impl_protected();
 
    def __A_foo_impl_private(self):
        pass;
 
    def _foo_impl_protected(self):
        pass
 
class B(A):
    def __B_foo_impl_private(self):
        print 'coin'
 
    def _foo_impl_protected(self):
        print 'coin coin'
 
if __name__ == "__main__":
    x = B()
    x.foo()

Par conséquent, quand tu tu appelles B().foo(), elle appelle A().foo() qui appelle A().__A_foo_private(). Et la, la virtualisation n'entre pas en jeu puisque les méthodes n'ont plus le même nom.

Le simple '_' est globalement reconnu comme étant la marque de visibilité pour les données interne, mais il faut faire attention avec le "__".

[PauseKawa]

Bonjour,

Mon c++ se limite avec le temps à hello world je vais donc rester sur la partie Python:

La notion de privé n'existe pas en Python.
Le double underscore sert pour éviter les conflits de nom.

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 A:
    def foo(self):
        self.__foo_impl_private()
        self._foo_impl_protected()
 
    def __foo_impl_private(self):
        print 'coin A'
 
    def _foo_impl_protected(self):
        print 'coin coin A'
 
class B(A):
    def __foo_impl_private(self):
        print 'coin B'
 
    def _foo_impl_protected(self):
        print 'coin coin B'
 
if __name__ == "__main__":
    x = B()
    print 'in B'
    print dir(x)
    x._A__foo_impl_private()
    x.foo()
    y = A()
    print 'in A'
    print dir(y)
    y.foo()

Code :

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

1
2
3
4
5
6
7
8
9
in B
['_A__foo_impl_private', '_B__foo_impl_private', '__doc__', '__module__', '_foo_impl_protected', 'foo']
coin A
coin A
coin coin B
in A
['_A__foo_impl_private', '__doc__', '__module__', '_foo_impl_protected', 'foo']
coin A
coin coin A

Comme vous le voyez Python transforme le nom (_A__foo_impl_private) de a fonction avant de la mettre dans l'espace de nom. C'est un 'jamais sans ma permission'.
Dans ce sens:

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 A:
    def foo(self):
        self.__foo_impl_private()
 
    def __foo_impl_private(self):
        print 1
 
class B(A):
    def __foo_impl_private(self):
        print 2
 
if __name__ == "__main__":
    x = B()
    x.foo()

Code :

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

1

Dans la logique c'est l'inverse de

Code :

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

1
2
3
4
5
6
7
8
9
class A
{
int foo() { return f();}
virtual int f() {return 2;}
};
class B : public A
{
virtual int f() {return 1;}
};

Code :

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

1
2
B instance;
int k = instance.foo();

il me semble et c'est pour cela que vous n'avez pas

Code :

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

1
2
coin
coin coin

lors de votre test car c'est

Code :

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

1
2
    def __foo_impl_private(self):
        pass;

qui est exécuté.

@+

Edit: grilled

[fred1599]

Alors tout d'abord, python, c'est pas du C++.

Faire du Python avec C++ est une énorme erreur.

En Python, une méthode privée n'est que succintement privée, on dira qu'elle est difficilement accessible.

La lisibilité du code est difficile, et n'est pas du tout du style d'un code python, __var = berk.

Le mode protégé n'existe pas en Python, seulement public ou privé.

Toutes les méthodes sont virtuelles.

Je le redis, penser C++ et utiliser Python est une grosse erreur, c'est une autre façon de penser, beaucoup moins de choses à gérer.

Si certaines fois on dit qu'un code n'est pas pythonic, c'est pas pour rien...

[PauseKawa]

La lisibilité du code est difficile, et n'est pas du tout du style d'un code python, __var = berk.

J'étais sur de voir ressortir la polémique .
Ce n'est effectivement pas dans les habitudes d'écriture mais cela existe et a son utilité. Il est vrais que la philosophie d'écriture fait que ce n'est pas très usité mais c'est comme dire 'utiliser un singleton c'est pas bien': Limiter les solutions.

Ceci dit je plussoie sur le fait que d’essayer de faire du C++ avec Python ne mène à rien si ce n'est a s’embrouiller les idées. La comparaison faite ici entre le private c++ et __ montre bien la différence de philosophie des deux langages.

Je m’arrête toutefois sur cette phrase:

Le mode protégé n'existe pas en Python, seulement public ou privé.

Pourrait on avoir un exemple ?

[fred1599]

J'insiste sur le fait que placer des underscores partout est non pythonic, j'avais vu certains gourou je ne sais plus dans quel bouquin dire que ça devrait carrément être retiré du langage et que c'était carrément une erreur.

Pourrait on avoir un exemple ?

Code :

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

1
2
3
4
5
6
7
class foo(): 
    def bar(self): pass 
    def __bar(self): pass 
 
f = foo() 
f.bar()   # ça fonctionne
f.__bar() # ça fonctionne pas

Evitez de prendre comme référence un autre langage, voir erreur 2

Certains livres disent de ne pas utiliser les "private methods" sans de très bonnes raisons.

Dans wikipedia, on voit ceci

Some consider information hiding to be unpythonic

Mais aussi

The slogan "We're all consenting adults here" is used to describe this attitude

[PauseKawa]

Cela ne fait que confirmer que les deux phrases suivantes:

Le mode protégé n'existe pas en Python, seulement public ou privé.

La notion de privé n'existe pas en Python.

sont fausses.

La première idée reçue lorsque l'on arrive du c++ c'est que:
Public
_Protected
__Private
Pour le Public pas de souci donc.
Le _ est souvent considéré comme une convention d'écriture (Ce qui n'est pas tout a fait le cas comme le montre import). En fait en Python cela correspond à 'internal/don't use'. Le programmeur étant considéré comme assez responsable pour le comprendre.
Le __ est considéré comme le private c++. Faux comme le montre l'héritage et les dir() de l'exemple si dessus. En fait il s'approche plus du protected et c'est ce qui est demandé de faire à l'interpréteur: protéger (_class__private). Mais comme dit pour _ le programmeur est responsable donc pourquoi l'utiliser ?

Et la je me dit mais c'est quoi ces salades ? Il n'y a pas de public/protected/private, seulement Python.

[fred1599]

@Pausekawa

On est d'accord, pour moi cette façon de faire en python reste tout simplement inutile.



Edit :

Je rajoute dans les bonnes pratiques sur biologeek cette phrase

Mais essayez d'éviter la forme __privée. Je ne l'utilise jamais. Faites moi confiance. Si vous l'utilisez, vous le regretterez plus tard.

Python n'a pas de mode protégé, Alan Gauld dit

Python has no protected mode, only the single underscore naming convention

Il dit aussi en répondant à la question, voulez-vous vraiment créer une méthode privée?

There are very few real cases where private methods are required and the norm in Python is for public methods, it makes for much more flexible classes

Très peu de cas sont nécessaires pour affirmer avoir besoin d'une méthode privée et la norme en python reste l'utilisation de la visibilité publique, et qui puis est rend le code et l'utilisation des classes plus flexibles.

[nikopol82]

Merci pour cet éclairage et ces excellentes lectures sur les bonnes pratiques pythoniques. Là ou le c++ fait de l'encapsulation une religion, le paradigme semble différent ici. En tous cas, merci à vous!

[PauseKawa]

C'est en effet une des grandes différences.
C'est aussi un des points importants, avec la considération que le programmeur est responsable, qui en fait un langage attirant.
Et ne vous inquiétez pas: Cette 'ouverture' n’empêche en rien de faire de la POO.

Bonne découverte et @+