difference entre attribut et _attribut ?

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

Code:

---

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 :/

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.

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

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) :)

Citation:

---

Envoyé par anthyme

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

---

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 :( ;)

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

Citation:

---

Envoyé par 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

---

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:

---

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:

---

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

Citation:

---

Envoyé par anthyme

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

Citation:

---

Envoyé par Thierry Chappuis

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:

---

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:

---

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:

---

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:

---

@property x

---

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

Code:

---

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)

Citation:

---

Envoyé par anthyme

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

Code:

---

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:

---

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:

---

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

---

Citation:

---

Envoyé par anthyme

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

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 ?

Citation:

---

Envoyé par 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 ?

---

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:

---

print MaClasse.x.__doc__

---

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

Thierry