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

[anthyme]

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

L'interet de faire un property juste pour un get set classique en python est a mon avi inutile mais dans ce cas la en C# tu peux etre encore plus conci ...

Code c# :

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

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

de plus j'aurai apprécié un système dans le style :

Code :

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

@property x

ou encore mieux une encapsulation grace à un mot clef au lieu d'une suite d'instructions :

Code :

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

1
2
3
property x:
    get:return self._x
    set:return self._x

ou quelque chose dans le genre ... mais plus conci que d'écrire une instruction entière pour finalement rediriger vers des méthodes ... car la on a quand même les méthodes "lourde" du java (getter et setter) + la déclaration de property du C# (en un peu lourde car une instruction entière)

bref les goûts et les couleurs d'accord ... mais bon pour des choses comme ça comme pour ceux qui trouve le perl élégant et bien moi je dis non ...

tiens puis ce que je suis partie la dedant je tiens a préciser un truc que j ai bien aimé dans le ruby vis a vis du python :

le to_s, to_i, sur tous les objet ... en effet appeller objet.to_s au lieu de str(objet), déjà d'un c'est plus logique quand tu code et pratique avec l'autocompletion (tu utilise ton objet et apres pense qu'il faut recuperer en str) mais surtout c bien plus objet ... appeler des fonctions prédéfinis par dessus un objet au lieu d'appeler des fonction même de l'objet (oui dans les fait cela appel une fonction de l'objet mais pkoi un tel mapping ? un objet.str() aurai été plus objet, pratique et élégant... oki je peux faire objet.__str__(), c objet cert mais c ni pratique ni élégant) sinon y a aussi le "self." remplacé par @ et c'est tres lisible et pratique ... bref au final je préfère le python pour d'autres raisons mais bon je pense qu'il faudrai qu'il évolue un peu car je le trouve un peu statique depuis un bon moment ...

vivement l'alpha de python 3 (normalement prevu pour ce mois)

[Thierry Chappuis]

ou encore mieux une encapsulation grace à un mot clef au lieu d'une suite d'instructions :

Code :

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

1
2
3
property x:
    get:return self._x
    set:return self._x

ou quelque chose dans le genre ... mais plus conci que d'écrire une instruction entière pour finalement rediriger vers des méthodes ... car la on a quand même les méthodes "lourde" du java (getter et setter) + la déclaration de property du C# (en un peu lourde car une instruction entière)

C'est pas tout à fait ça, mais on y est presque. Tu commences par définir la métaclasse et la classe suivante:

Code :

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

1
2
3
4
5
6
7
8
9
10
class MetaProperty(type):
    def __new__(mcl, name, bases, dict):
        if name == 'Property':
            return super(MetaProperty, mcl).__new__(mcl, name, bases, dict)
        else:
            return property(dict.get('get'), dict.get('set'), dict.get('del'),
                            dict.get('__doc__') or "Property %s" % name)
 
class Property:
    __metaclass__ = MetaProperty

Ensuite, c'est dans la poche. Tu peut écrire:

Code :

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

1
2
3
4
5
6
7
8
class MaClasse(object):
    def __init__(self, x):
        self._x = x
 
    class x(Property):
        """Je suis la propriété x."""
        def get(self): return self._x
        def set(self, value): self._x = value

le to_s, to_i, sur tous les objet ... en effet appeller objet.to_s au lieu de str(objet), déjà d'un c'est plus logique quand tu code et pratique avec l'autocompletion (tu utilise ton objet et apres pense qu'il faut recuperer en str) mais surtout c bien plus objet ... appeler des fonctions prédéfinis par dessus un objet au lieu d'appeler des fonction même de l'objet (oui dans les fait cela appel une fonction de l'objet mais pkoi un tel mapping ? un objet.str() aurai été plus objet, pratique et élégant... oki je peux faire objet.__str__()

Rien ne t'empêche d'écrire une métaclasse qui définit une méthode to_s lorsque __str__ est définie... C'est ce que j'aime avec Python. La flexibilité poussée à l'extrême.

Thierry

[anthyme]

hummm c'est vrai que c'est pas mal mais je vois tout de même 2 problème :

- manque de standardisation : il faut penser à la (les) personne qui va passer après toi, réinventer le langage pour des choses aussi "bas" niveau (je parle au niveau du langage pas de la machine) n'est pas bon pour le travail colaboratif.
Ce genre de features devrait être pré intégré.

- je n'ai jamais fait de metaprog et ton code m'apparaît comme étant un peu ... austère je ne le critique pas en mal mais me pose juste cette question : Quid des performances ?

[Thierry Chappuis]

hummm c'est vrai que c'est pas mal mais je vois tout de même 2 problème :

- manque de standardisation : il faut penser à la (les) personne qui va passer après toi, réinventer le langage pour des choses aussi "bas" niveau (je parle au niveau du langage pas de la machine) n'est pas bon pour le travail colaboratif.
Ce genre de features devrait être pré intégré.

- je n'ai jamais fait de metaprog et ton code m'apparaît comme étant un peu ... austère je ne le critique pas en mal mais me pose juste cette question : Quid des performances ?

J'ai simplement montré qu'on peut le faire, mais la métaprogrammation est un sujet avancé. Sur le plan de la performance, le code que j'ai posté plus est strictement équivalant à un appel explicite à property().

Il est clair que réinventer le langage de cette manière nuit au travail collaboratif, mais c'est possible, et on rencontre des cas de figure où c'est souhaitable.

EDIT: En passant, cette manière de faire automatise l'accès à la docstring de la propriété x:

Code :

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

print MaClasse.x.__doc__

Ceci peut avoir un effet bénéfique sur le travail collaratif.

Thierry