Discussion :

[master4]

Bonsoir,

Contrairement à d'autres langages de programmation comme java où le principe d'encapsulation est vraiment respecté (attribut private ou protected). En python, ce n'est pas la cas. Alors, je voudrais savoir quel serait son importance en python si on a toujours la possibilité d'accéder à une variable protégée hors classe. Par exemple :

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 P:
 
    def __init__(self,x):
        self.__x = x
 
    def get_x(self):
        return self.__x
 
    def set_x(self, x):
        self.__x = x
 
p1 = P(12)
p1._P__x 
>>>12

[Sve@r]

Alors, je voudrais savoir quel serait son importance en python si on a toujours la possibilité d'accéder à une variable protégée hors classe.

Bonjour

C'est un fait connu des programmeurs Python qui l'acceptent. Donc l'importance sera celle que toi tu lui donnes par rapport à tes besoins, ton environnement de travail (seul, en groupe), etc...

[VinsS]

Salut,

Ceci suit le principe qui veut que "En Python nous sommes adultes et consentants"

Maintenant, tu peux rendre un attribut en lecture seule par divers moyens.
Exemple:

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
 
class P:
    _instanciated = False
    def __init__(self,x):
        self.__x = x
        self.y = 6
        self._instanciated =True
 
    def __setattr__(self, name, value):
        if self._instanciated and name == '__x':
            raise NotImplementedError
        setattr(P, name, value)
 
p = P(24)
print(p.__x)
print(p.y)
p.__x = 14

[fred1599]

Je suis d'accord avec Sve@r, dans le sens où tout dépendra du besoin... Après tout, tout se justifie !

Alors pourquoi pas d'encapsulation en python,

• Code facile à lire et à comprendre
• La concision du code (il est inutile de faire du setter-getter et se blinder de lignes à n'en plus finir)
• La maintenance du code facile (modifier un attribut dynamiquement est un jeu d'enfants)

Et comme la philosophie du langage "zen of python" le dit: Simple is better than complex, tout cela tombe sous le sens.

Maintenant si tu en as besoin, pourquoi pas, dans ce cas on utilise les property qui permettent de contrôler la lecture-écriture-suppression des attributs dans une classe. La PEP8 dit ceci,

For simple public data attributes, it is best to expose just the attribute name, without complicated accessor/mutator methods. Keep in mind that Python provides an easy path to future enhancement, should you find that a simple data attribute needs to grow functional behavior. In that case, use properties to hide functional implementation behind simple data attribute access syntax.

avec une petite parenthèse,

Avoid using properties for computationally expensive operations; the attribute notation makes the caller believe that access is (relatively) cheap.

Alors même si tu en sens le besoin, réfléchis bien ! Les conséquences sont assez nombreuses... et plus il y a de conséquences, plus on te demandera de justifier tes choix de conception. En python on cherche le maximum de simplicité, ce qui impose un maximum de responsabilité, et ça n'empêche absolument pas python d'être performant, tant dans l'écriture du code, que dans l'exécution des tâches.

[wiztricks]

Salut,

Alors, je voudrais savoir quel serait son importance en python si on a toujours la possibilité d'accéder à une variable protégée hors classe.

Si vous utilisez les variables protégées de la bibliothèque X créée par le développeur D vous aurez (peut être) des soucis si, à la version suivante, le développeur D, supprime ou modifie ces variables. Comme elles ne font pas partie de l'"interface publique", il est libre de les utiliser comme il veut... Et si votre code ne fonctionne plus parce que vous n'avez pas respecté l'interface, c'est votre problème (pas le sien).

Donc à court terme, votre code fonctionne... mais à plus long terme, il faudra (peut être) le revoir. Avec un mécanisme de protection fort, comme on le trouve dans Java ou C++, impossible d'utiliser une variable/attribut protégé. Et le risque d'avoir à revoir le code à cause de cela est nul.... et vous pouvez installer/utiliser les nouvelles versions des bibliothèques, à priori, sans risque dès que l'interface publique reste identique.

Ceci dit, attributs privés et protégés existent bel et bien et si rien n'est testé lorsqu'on exécute un script qui accède à des attributs protégés, on peut lire le code ou l'analyser avec un pylint ou équivalent (qui testent aussi ce genre de chose).
Donc, c'est un petit risque dont on peut se protéger, en cas de besoin.

- W

[Sve@r]

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
 
class P:
    _instanciated = False
    def __init__(self,x):
        self.__x = x
        self.y = 6
        self._instanciated =True
 
    def __setattr__(self, name, value):
        if self._instanciated and name == '__x':
            raise NotImplementedError
        setattr(P, name, value)
 
p = P(24)
print(p.__x)
print(p.y)
p.__x = 14

Il me semble que ton print(p.__x) ne fonctionnera pas (puisque la variable se nomme en réalité p._P__x). De même le test name == '__x' devrait plutôt être name == '_P__x'. Ceci dit j'apprécie ce code et son inventivité

[VinsS]

Bien vu, j'ai copié la première mouture, le bon code est 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
 
class P:
    _instanciated = False
    def __init__(self,x):
        self.x = x
        self.y = 6
        self._instanciated =True
 
    def __setattr__(self, name, value):
        if self._instanciated and name == 'x':
            raise NotImplementedError
        setattr(P, name, value)
 
p = P(24)
print(p.x)
print(p.y)
p.x = 14

et donc

Code :

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

1
2
3
4
5
6
7
8
9
10
 
vincent@djoliba:~/Bureau$ python3 private.py 
24
6
Traceback (most recent call last):
  File "private.py", line 16, in <module>
    p.x = 14
  File "private.py", line 10, in __setattr__
    raise NotImplementedError
NotImplementedError

La raison d'utiliser "setattr(P, name, value)" est parce que "setattr(self, name, value)" entrainerait une récursion infinie.

[Sve@r]

La raison d'utiliser "setattr(P, name, value)" est parce que "setattr(self, name, value)" entrainerait une récursion infinie.

J'ai bien vu quand j'ai testé avec "self"

C'est dommage car ça implique le nom de la classe dans une de ses méthodes. Si le nom change, faut reprendre le code...

J'ai trouvé une solution pour pallier : eval("setattr(%s, %s, %s)" % (self.__class__.__name__, name, value)) (mais faut que ton objet hérite de "object") (et surtout que wiztricks ne voit jamais mon eval )...

[edit]Euh en fait il y a un autre souci: "_instanciated" est un membre de classe statique. Il existe donc à un seul exemplaire pour toutes les instances de ton objet. Rajoute p2 = P(42) en dessous de ton p = P(24) et
J'ai trouvé un truc mais là c'est le grand bricolage de la honte...

Code python :

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

1
2
3
4
5
6
7
8
9
10
11
class P(object):
	def __init__(self, x):
		self._instanciated=False
		self.__x=x
		self._instanciated=True
	def __setattr__(self, name, value):
		if hasattr(self, "_instanciated")\
			and self._instanciated\
			and name.startswith("_%s__" % self.__class__.__name__):
			raise AttributeError("%s" % name)
		setattr(P, name, value)

il diffère un peu car je l'ai écrit dans le but de protéger juste les membres privés (commençant par "__")...

[master4]

Merci à tous de vos réponse !
Si j'ai bien compris ce que vous avez dit. On peut donc créer un programme en Python sans utiliser le principe d’encapsulation et ne pas avoir des problèmes par la suite ?

[Sve@r]

Si j'ai bien compris ce que vous avez dit. On peut donc créer un programme en Python sans utiliser le principe d’encapsulation et ne pas avoir des problèmes par la suite ?

Les soucis ne viennent que de la façon de faire des développeurs. Si tu bosses avec des gens consciencieux qui savent ce qu'ils font et qui respectent les conventions, tu n'auras jamais de problème (y compris dans les langages encapsulés comme Java ou C++).

[master4]

Les soucis ne viennent que de la façon de faire des développeurs. Si tu bosses avec des gens consciencieux qui savent ce qu'ils font et qui respectent les conventions, tu n'auras jamais de problème (y compris dans les langages encapsulés comme Java ou C++).

Là, je commence à voir un peu plus clair. Donc vu que les programmes qu'on développe sont appelés, tôt ou tard, à être modifiés ou bidouillés par des tierces personnes qui nous seront peut-être inconnues. Il est donc plus judicieux de toujours encapsuler ?

[nicolas581]

https://www.python-course.eu/python3_properties.php : pour une explication pratique

Ne pas mettre des getters/setters avant d'en avoir besoin s'approche de https://fr.wikipedia.org/wiki/YAGNI

[master4]

https://www.python-course.eu/python3_properties.php : pour une explication pratique

Ne pas mettre des getters/setters avant d'en avoir besoin s'approche de https://fr.wikipedia.org/wiki/YAGNI

Moi, je me dit que pour me prémunir contre les éventuels personnes mal intentionnées qui pourraient détruire le programme que je développe. Il est mieux de protéger mes variables. Si par exemple, je me dis : "bon, pour mon programme, je n'ai pas besoin d'encapsuler mes variables, car personne ne pourrait mal les utiliser...". Là, je trouve que je cours un risque parce que je ne connais pas l'intention de tout le monde. Pour assurer sa sécurité autant tout protéger, mieux vaut "prévenir que guérir".

[fred1599]

Moi, je me dit que pour me prémunir contre les éventuels personnes mal intentionnées qui pourraient détruire le programme que je développe. Il est mieux de protéger mes variables. Si par exemple, je me dis : "bon, pour mon programme, je n'ai pas besoin d'encapsuler mes variables, car personne ne pourrait mal les utiliser...". Là, je trouve que je cours un risque parce que je ne connais pas l'intention de tout le monde. Pour assurer sa sécurité autant tout protéger, mieux vaut "prévenir que guérir".

Que tu protèges ou non tes variables ne changera rien, étant donné qu'il aura accès à ton code pour faire cette modification.

Quand on utilise un langage tel que python, il est rare d'avoir le besoin de protéger la lecture du code, mais si c'est le cas, on peut déjà le rendre moins facilement lisible pour 98% des utilisateurs lambda, rien que par une compilation.

Après pour plus de sécurité, c'est bien plus complexe, mais sur les 2% qui liront ton code, 1% seront capables de le déchiffrer et diffuser sur le net pour cette fois-ci un grand nombre de personnes. Mais pour ça faut-il que le code en vaille la chandelle, et que le prix du logiciel soit prohibitif.

[Sve@r]

Là, je commence à voir un peu plus clair. Donc vu que les programmes qu'on développe sont appelés, tôt ou tard, à être modifiés ou bidouillés par des tierces personnes qui nous seront peut-être inconnues. Il est donc plus judicieux de toujours encapsuler ?

Pourquoi faire ?
Si les tierces personnes modifient et que, suite à ces modifs, ton programme ne fonctionne plus chez-elle, ce sera leur problème...

[master4]

Pourquoi faire ?
Si les tierces personnes modifient et que, suite à ces modifs, ton programme ne fonctionne plus chez-elle, ce sera leur problème...

Pourriez-vous me donner quelques exemples des cas où ce serait pertinent d'encapsuler ?

[wiztricks]

Pourriez-vous me donner quelques exemples des cas où ce serait pertinent d'encapsuler ?

Quand vous écrirez du code où ne pas le faire pourrait se traduire par une perte de temps (et/ou de revenus)... i.e. lorsque vous ne pourrez pas vous permettre de prendre ce risque.
Autrement dit, protéger les attributs n'ajoutant rien aux fonctionnalités du code, il pourra être pertinent d'encapsuler qu'en fonction d'un contexte non-technique: le client, le type d'application, les engagements des différents intervenants côté maintenance, performances,....

- W

[Sve@r]

Pourriez-vous me donner quelques exemples des cas où ce serait pertinent d'encapsuler ?

Chaque fois que ça te permettra de contrôler ce qui entre tout en laissant l'utilisateur libre de travailler

Prenons un exemple tout con: un objet destiné à gérer une personne

Code python :

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

1
2
3
class cPersonne(object):
	def __init__(self, nom):
		self.nom=nom

Avec cet objet, l'utilisateur peut très bien créer une personne puis afficher ou changer ensuite son nom

Code python :

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

1
2
3
4
v=cPersonne("Arthur")
print(v.nom)
v.nom="Perceval"
print(v.nom)

voire aussi y mettre rien du tout (v.nom="").

Maintenant, si on place le nom en privé mais qu'on rajoute un getter et un setter...

Code python :

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

1
2
3
4
5
6
7
8
class cPersonne(object):
	def __init__(self, nom):
		self.__nom=nom
	def __get_nom(self): return self.__nom
	def __set_nom(self, nom):
		if not nom: raise IOError("Pas de nom vide")
		self.__nom=nom
	nom=property(__get_nom, __set_nom)

Avec ça, rien ne change pour l'utilisateur. Il peut toujours créer sa personne et afficher ou changer de nom sans même changer sa syntaxe habituelle (copier/coller de mon code précédent)

Code python :

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

1
2
3
4
v=cPersonne("Arthur")
print(v.nom)
v.nom="Perceval"
print(v.nom)

Chaque fois qu'il fait appel à v.nom, si c'est en sortie alors le bouzin appelle en interne __get_nom et si c'est en affectation alors ça appelle __set_nom.
Mais là toi tu contrôles ce qui entre. Et s'il tente d'entrer un nom vide, là il aura un "IOError" qu'il peut alors gérer de son côté.

Bref je vois ça plus comme une volonté "d'aide" à l'utilisateur qu'une volonté de le bloquer (même si quelque part les deux vont un peu ensembles). Disons que ça le bloque un peu mais ça évite ensuite à ton truc de planter parce qu'il aura entré n'importe quoi.
Maintenant, s'il force le truc et qu'il tape v._cPersonne__nom=None et qu'il vient ensuite pleurer parce que ça plante, tu lui diras gentiment d'aller se faire...

[wiztricks]

Chaque fois que ça te permettra de contrôler ce qui entre tout en laissant l'utilisateur libre de travailler

Sauf que "property" et "protection des variables" n'ont rien à voir (et donc on ne les utilise pas pour les mêmes besoins).

- W

[master4]

Quand vous écrirez du code où ne pas le faire pourrait se traduire par une perte de temps (et/ou de revenus)... i.e. lorsque vous ne pourrez pas vous permettre de prendre ce risque.
Autrement dit, protéger les attributs n'ajoutant rien aux fonctionnalités du code, il pourra être pertinent d'encapsuler qu'en fonction d'un contexte non-technique: le client, le type d'application, les engagements des différents intervenants côté maintenance, performances,....

- W

Merci !