Discussion :

[kedare]

Hello ,
j'ai une question , je vient de tomber sur ce code :

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 Contact(object):
 
    def __init__(self, first_name=None, last_name=None, 
                 display_name=None, email=None):
        self.first_name = first_name
        self.last_name = last_name
        self.display_name = display_name
        self.email = email
 
    def print_info(self):
        print self.display_name, "<" + self.email + ">"            
 
    def set_email(self, value):
        if '@' not in value:
            raise Exception("This doesn't look like an email address.")
        self._email = value
 
    def get_email(self):
        return self._email
 
    email = property(get_email, set_email)

seulement je le trouve .. etrange ,
au niveau des attribut , j'ai remarquer due email et _email on toujours la meme valeur .. pourquoi ? ce sont les memes variables (meme apres l'initialisation de l'objet ou _email est pas defini , la methode get_mail (appelé via me.email) renvoie la valeur de email (alors que dans le code c'est _email)...
je comprend pas trop pourquoi :/

[Guigui_]

en général, on utilise les _attribut pour marquer un attribut de type private. Mais ce n'est qu'une règle de codage

Ensuite email est une property qui permet de manipuler (écriture/lecture) l'attribut _email (mais de manière transparente pour l'utilisateur) comme dans tout autre langage. Ca permet d'éviter qu'on mette n'importe quoi dans la variable _email vu qu'il y a un contrôle derrière avant d'écrire dans cette variable.

[anthyme]

je trouve qu'en python toutes ces manipulation rendent le code moins propre et lisible que si on s'en passait

[kedare]

c'est vrais que crée des accesseur via une methode ca fait bizare ...
c'est mieu comme fait ruby ...
un coup de attr_accessor :mon_attribut pour tout automatiser , voir def mon_attribut=(value)

[Invité]

je trouve qu'en python toutes ces manipulation rendent le code moins propre et lisible que si on s'en passait

Certes ! Je trouve pas que ce soit forcément la syntaxe la plus belle, surtout le "nomProperty = property (methode1, methode2)" que je trouve passablement immonde...

En revanche, c'est quand même très pratique à l'usage, j'ai découvert ce principe en C# il y a peu de temps (c'est la même chose ici si je ne m'abuse), et je trouve ça excellent (mais bon il est vrai qu'en C# on se retrouve souvent avec des attributs private, pas en python). Même si Python n'a pas l'encapsulation stricte qu'ont des langages comme Java, C#, C++, ... je trouve ce genre de pratique très intéressant pour effectuer un contrôle de l'accès aux attributs de façon transparente pour l'utilisateur.

Bref, j'aime beaucoup le principe, juste la syntaxe que je trouve horrible

[anthyme]

Moi je code plus en C#/java qu'en python (hélas?) et c'est vrai que c'est très propre dans ces langage mais en python il ne s'agit qu'un ajout proche du bidouillage (surement à la demande de quelques utilisateur) qui est à l'encontre même de la philosophie de python : un code clair (kedare qui de ce que je sais est un bon codeur n'as pas reussi a lire ce code, pour moi c pas acceptable).

Et si encore cela avait vraiment le role de contrôler les acces a cette variable ... mais non pas du tout tu peux toujours accéder a cette variable via objet._variable.

Heureusement il y a quand même l'utilité de faire un contrôle ce que l'on insert mais bon ... je préfère encore passer par une méthode.

C'est vraiment dommage que ce soit si moche

[Thierry Chappuis]

Moi je code plus en C#/java qu'en python (hélas?) et c'est vrai que c'est très propre dans ces langage mais en python il ne s'agit qu'un ajout proche du bidouillage (surement à la demande de quelques utilisateur) qui est à l'encontre même de la philosophie de python : un code clair (kedare qui de ce que je sais est un bon codeur n'as pas reussi a lire ce code, pour moi c pas acceptable).

Et si encore cela avait vraiment le role de contrôler les acces a cette variable ... mais non pas du tout tu peux toujours accéder a cette variable via objet._variable.

Heureusement il y a quand même l'utilité de faire un contrôle ce que l'on insert mais bon ... je préfère encore passer par une méthode.

C'est vraiment dommage que ce soit si moche

Il ne s'agit pas d'un ajout proche du bidouillage, décidé à la va vite, comme tu sembles le penser. Un propriété n'est rien d'autre qu'un objet qu'on appelle un descripteur de donnée, et les descripteurs sont au centre de tout le mécanisme des classes nouveau style.

Maintenant, en ce qui concerne l'élégance de la méthode, c'est comme les goûts et les couleurs... Personnellement, je suis impressionné par la cohérence du modèle objet de Python et la syntaxe proposée ne me gène pas outre-mesure:

Code c# :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
// En C#
class MaClasse {
 
   /* ... */
   private _x;
 
   public x {
       get { return _x; }
       set { _x = value; }
   }
}

ou

Code :

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

1
2
3
4
5
6
7
8
9
10
# Son équivalent Python
 
class MaClasse(object):
    def __init__(self, x):
        self._x = x
 
    # x propery definition
    def getx(self): return self._x
    def sety(self, value): self._x = value
    x = properpy(getx, setx)

Je trouve personnellement la manière pythonique plus explicite.

EDIT: Par ailleurs, il est facile d'automatiser la créations des propriétés avec un peu de métaprogrammation, mais ça c'est une autre histoire.

Thierry

[Thierry Chappuis]

Et si encore cela avait vraiment le role de contrôler les acces a cette variable ... mais non pas du tout tu peux toujours accéder a cette variable via objet._variable.

En Python, l'encapsulation est une question de convention. Les créateurs du langage ont pris le parti de faire confiance au bon sens des programmeurs. Un bon programmeur Python sait que, par convention, les attributs dont le nom est précédé de un ou deux caractères de soulignement sont privés. Certes, le programmeur en question peut accéder directement à ces attribut, mais quel avantage gagnerait-il à casser l'encapsulation?

Thierry