utilité des classes, différence entre classe et fonction

Bonjour dividee

Citation:

---

Envoyé par dividee

Rien ne l'empêche ? Peut-être, mais honnêtement, as-tu appris initialement le concept d'interface en Python ? Cela m'étonnerait...

---

et bien pour répondre honnêtement à ta question: oui. par exemple, le simple fait qu'on puisse itérer de la même manière sur un fichier, une liste, une chaine de texte... avait déjà commencé à me sensibiliser, même si le terme interface ne me serait pas venu à l'esprit. et puis il y a eu un hors-série GNU Linux magazine présentant la Zope Component Architecture. Et c'est en me renseignant sur cette dernière que j'ai mieux cerné les interfaces. C'est en discutant avec des développeurs Java que je me suis rendu compte que les concepts étaient très proche (et même les "mot clés" comme "implements")

Citation:

---

Envoyé par dividee

Ben si le langage a une influence sur la qualité de l'autocomplétion. En Java, une simple analyse syntaxique suffit généralement pour l'autocomplétion, en Python c'est beaucoup plus difficile car sans exécuter le code, on ne peut pas être sur du type d'un variable (en fait, on ne peut même pas être sûr qu'elle existe). C'est l'un des avantages du typage statique... Je suis souvent déçu de la qualité de l'autocomplétion en Python, mais je sais pourquoi elle est médiocre.
En C++ c'est plus complexe aussi, car le typage peut être contourné (héritage du C), et la métaprogrammation par templates complique peut être aussi les choses (pas sûr, à voir).

---

je comprends bien, mais on a d'un côté un langage très verbeux avec une autocomplétion ultra efficace et de l'autre un langage moins verbeux (3 à 4 fois moins de lignes requises) avec une autocomplétion de moins bonne qualité. Qu'on essaie pas de faire entendre qu'en Java on écrit du code beaucoup plus vite ;)

Citation:

---

Envoyé par dividee

Je suis partiellement d'accord, mais il serait encore plus néfaste de considérer Python comme la référence en matière d'orientation objet. Python a une couche OO intéressante et relativement simple de par le typage dynamique; certains concepts ne prennent vraiment un sens qu'en typage statique (par exemple, le polymorphisme et les génériques) et ce serait dommage de passer à côté.

---

ne me fais pas dire ce que je n'ai pas dit :) Je n'ai pas dit que Python devait être considéré comme une référence. J'ai même dit qu'il était bénéfique de voir le modèle objet d'un autre langage en parallèle. Mais pourquoi ? Tout simplement parce que cette approche permet de faire la différence entre ce qu'est vraiment l'approche orientée objet, en tant que technique de conception, des détails d'implémentation propres à chaque langage (ou à chaque famille de langage). C'est d'autant plus vrai qu'il est à mon sens difficile de trouver des ressources qui expliquent ce qu'est l'approche objet indépendamment d'un langage.

Citation:

---

Envoyé par Zavonen

Une des lacunes majeures de la couche objet de python est l'absence de véritables constructeurs rendant impossible la promotion automatique de type, qui est à mon avis un mécanisme fondamental permettant l'identification. C'est par exemple ce principe qui nous permet d'assimiler les entiers à certains rationnels, les rationnels à certains réels, les réels à certains complexes, etc..
Ainsi des écritures telles que r=2 où r est un rationnel prennent tout leur sens devant être comprises comme r=2/1
ou bien x=3/2 quand x est un réel
ou bien encore z=2 quand z désigne un complexe.
Voici donc deux exemples simples et parallèles l'un en python l'autre en C++

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

class Truc(): def __init__(self,x): self.value=x def __add__(self,y): return self.value+y.value   A=Truc(1) B=Truc(2) print A+B print A+2   """ résultat 3 AttributeError: 'int' object has no attribute 'value' """

---

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

class Truc(): def __init__(self,x=0): self.value=x def __add__(self, x): if type(x) == type(0): return Truc(self.value + x) if type(x) == type(Truc()): return Truc(self.value + x.value) def __str__(self): return "%d" % self.value   A=Truc(1) B=Truc(2) print A+B => 3 print A+2 => 3 C=A+B+1 print C => 4 C => <__main__.Truc instance at 0x00BFD620>

---

Ben oui, l'autopromotion n'existant pas, je me la farcis moi-même...

Truc plus court...

Code:

---

1 2 3 4 5 6

class Truc(int): def __new__(cls, value=None): return int.__new__(cls, value)   def __add__(self, x): return Truc (super(Truc,self).__add__(x))

---

Il faudrait l'éclairage de Dividee là dessus: avec le temps, la rigueur n'est plus dans mes passions! Mais la remarque de Zavonen porte plutôt ou aussi sur le polymorphisme, i.e. écrire des méthodes "généralisables" à différents "types".
Le fait est que les langage "statiques" n'ont pas d'autre choix que de passer par l'héritage (ou l'interface) pour réaliser cela alors qu'en "dynamique", la "réflexion" fait disparaître le problème.

Par exemple, si on écrit une fonction carré, style:
def carré(x):
return x * x
Nous pourrons l'appliquer indifféremment à des float, int, ... ou à n'importe quel objet pour lequel l'opération * a un sens.

Ceci dit, il est vrai que Python manque de 'verbes' pour accroître contrôle et précision mais c'est plus côté ajout d'abstractions aux objets que pour se rapprocher des langages statiques.
Et çà gamberge un peu sur le sujet, voir:

• http://www.python.org/dev/peps/pep-3119/
• http://www.python.org/dev/peps/pep-3141/
• http://www.python.org/dev/peps/pep-3133/

Note: Ca ne raconte rien qu'on ne puisse avoir déjà çà définit juste des "verbes" que l'on pourra partager plutôt que de réaliser/utiliser sa propre sauce.
- W

On résume souvent la P.O.O. de la façon suivante:

• Encapsulation
• Protection des données
• Héritage
• Polymorphisme

De ce point de vue on peut évaluer python

• Encapsulation: normal-bon
• Protection des données: nul (non implémenté)
• Héritage: normal mais la syntaxe laisse à désirer (on se perd dans les super ...)
• Polymorphisme: Nul (voir les remarques ci-dessus concernant les interfaces, pas de classes abstraites, voir ci-dessus les problèmes de conversion, les surcharges d'opérateurs sont assez mal traitées à cause d'un grand nombre de mots clés à ingurgiter du genre __mul__ distinction avec __rmul__ etc, bref bricolage)

Ceci n'est qu'un jugement (le mien) sur un seul des aspects de ce langage (la couche objet). Il ne s'agit donc pas d'un jugement de valeur sur l'ensemble.
Je sais par expérience qu'il existe sur ce forum un 'fan club' avec ses 'pom-pom-boys'. A leur intention je signale que la présence même sur ce forum implique un intérêt pour le langage python (on a autre chose à faire que perdre du temps à dénigrer).
Cependant il doit rester permis de mettre en lumière les défauts et les insuffisances qui sont parfois le résultat de choix qui font la qualité du langage. Bref, en programmation comme ailleurs on ne peut avoir le beurre et l'argent du beurre.

• Python est un bon langage pour apprendre (pas de sons discordants sur ce point).
• Python est commode et pratique par son aspect non dogmatique (multi-paradygmatique)
• Python est simple et sa syntaxe particulièrement claire fait qu'il remplace avantageusement tous les pseudocodes existant pour la présentation d'algorithmes.
• Python en temps que langage de scripts (de glu pour lier les bibliothèques) est parfait
• Python est parfait pour le prototypage de projets (on écrit très vite des choses qui fonctionnent).

Bref il y a beaucoup de raisons d'adopter et de défendre python. Cela dit ceux qui poursuivent le mythe du langage universel, du langage à tout faire, du langage ultime seront déçus par python (comme par les autres). Les programmeurs doivent s'habituer à vivre dans la diversité. Si vous programmez uniquement des calculs scientifiques on n'a guère fait mieux que fortran (qui dit-on bat même C en vitesse pure). Cobol reste d'actualité pour les programmes de gestion, SQL pour les bases de données. Lisp est loin d'être dépassé en intelligence artificielle, etc...
On peut même utiliser python pour initier à la P.O.O. en ne prenant en considération que les concepts d'encapsulation et d'héritage. C'est d'ailleurs peut-être une bonne façon de faire puisque ce sont les concepts les plus accessibles.

Citation:

---

Ben oui, l'auto-promotion n'existant pas, je me la farcis moi-même...

---

Sauf que l'auto-promotion à la C++ fonctionne récursivement et marche avec l'auto-promotion des types primitifs.
Exemple si Truc2 admet un constructeur avec un argument Truc1 et si Truc1 admet un constructeur avec un argument complexe, on peut (par exemple) additionner un Truc2 avec un argument entier.
Ça fait beaucoup de trucs à se farcir.

Citation:

---

Envoyé par Zavonen

[*]Polymorphisme: Nul (voir les remarques ci-dessus concernant les interfaces, pas de classes abstraites, voir ci-dessus les problèmes de conversion, les surcharges d'opérateurs sont assez mal traitées à cause d'un grand nombre de mots clés à ingurgiter du genre __mul__ distinction avec __rmul__ etc, bref bricolage)

---

Bonjour Zavonen,

J'ai besoin d'un éclaircissement. Prenons un exemple (tiré de la définition de classe abstraite dans wikipedia):

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

class Humain(object): def sexe(self): return self._sexe   class Homme(Humain): def __init__(self): self._sexe = "M" Humain.__init__(self)   class Femme(Humain): def __init__(self): self._sexe = "F" Humain.__init__(self)

---

- sommes nous d'accord que Humain, bien que non déclarée explicitement comme une classe abstraite, est une classe abstraite ? Dans le sens ou son implémentation est incomplète.

- est-ce le fait qu'elle soit instanciable néanmoins (rien n'empêche d'instancier un objet de type Humain) et que cette instance soit inutilisable qui pose problème selon toi ?

Je partage ta remarque sur les noms des opérateurs pour les surcharges. J'ai à chaque fois besoin de rechercher dans la doc qu'elle méthode je dois définir.

Je peux aussi prendre cet exemple là:

Code:

---

1 2 3 4 5 6 7 8 9

class Forme(object): def aire(self): return 0.   class Carre(Forme): def __init__(self, a=0.): self._a = a def aire(self): return self._a * self._a

---

Le point que je partage encore plus, indépendamment de ce sujet précis, c'est le polymorphisme par surcharge paramétrique et plus particulièrement pour le constructeur. Cela oblige à passer par des factory. Mais il n'y a pas de notion de signature de fonction en Python, ou alors si, il y a une notion de signature mais qui se limite au nom de la fonction, de sorte que 2 fonctions de même nom (dans la même portée) aient exactement la même signature.

Et je ne défends pas du tout le mythe du langage universel, ce serait idiot vu le nombre de librairies Python que j'utilise tous les jours et qui sont codées en C, C++ ou Fortran :D

Citation:

---

Envoyé par Zavonen

Une des lacunes majeures de la couche objet de python est l'absence de véritables constructeurs rendant impossible la promotion automatique de type, qui est à mon avis un mécanisme fondamental permettant l'identification. C'est par exemple ce principe qui nous permet d'assimiler les entiers à certains rationnels, les rationnels à certains réels, les réels à certains complexes, etc..

---

Parler de "lacune majeure" me semble un peu fort. Cela ne me semble pas central à la conception orientée objet. C'est sympathique à avoir, mais cela n'a de sens que dans un langage où le type des paramètres est déclaré.
En Python, la surcharge de méthodes n'existe pas non plus, ni sur les types des paramètres (forcément), ni sur leur nombre vu que Python privilégie un système avec nombre d'arguments variables. La promotion de type et la surcharge vont main dans la main (ils se complètent bien), mais à choisir, la surcharge me semble est un mécanisme plus fondamental que la promotion de types.

Code:

---

Truc T2 =2; // Cette syntaxe réalisant l'identification n'est pas admise en python

---

Ben forcément si on déclare pas les types. T2 = Truc(2) c'est pas fort différent à écrire, et c'est plutôt l'équivalent de Truc *T2 = new Truc(2); (en fait, ce serait encore plus proche en utilisant un "smart pointer") car en Python l'allocation sur la pile n'existe pas.


[EDIT:] Encore une fois, je n'avais pas remarqué qu'il y avait une seconde page. Ca commence à être une habitude :( Enfin bon, mon post a tout de même un sens.

bonsoir,

Citation:

---

Envoyé par kango

post intéressant que celui-ci :)

---

Même remarque, sur cette discussion, quand bien même le pauvre homme qui à poser la question au départ doit planer un peu...

Citation:

---

Envoyé par kango

des mots clés usuels dans d'autres langages :) Je m'explique, le modèle objet de C++ par exemple est très rigide à mon goût (la nécessité des public, private, protected) ce qui pourrait être considéré comme une force. Mais dans le même temps, il met à disposition des moyens de contournement (les relations d'amitié). Je trouve que c'est une belle ambiguité dans la couche objet de C++ :) Et si on n'a rien compris à l'encapsulation, je pense qu'on peut voir de belles cochoneries en C++ aussi avec ça :)

---

Les mots clés que je mentionne sont ceux qui font face aux concepts que l'on retrouve en modélisation UML... public, private, protected en font partie... abstract et interface de même... Je ne prendrais pas, mais vraiment pas C++ comme modèle pour la programmation Objet (Les méthodes virtuelles sont là pour émulée abstract et le polymorphisme... La complexité engendrée et les erreurs qui en résultent sont terribles)...

A mon sens, public, private et protected sont indispensables pour fournir des classes :
- Que l'utilisateur ne peut pas mal utiliser (protected pour l'héritage en C++)
- Qui peuvent évoluer en interne sans conduire l'utilisateur à revoir tout son code (private)

Quand à l'amitié en C++, sans elle, il est de rare cas où son absence priverait de la possibilité de découpler une classe en deux classes fortement liées... Mais bon, on peut toujours faire des mauvaises utilisations. Il arrive de voir en Java comme en C++ des exceptions lancées avec le message ("Not yet implemented")... D'où viennent de telles habitudes ;)

Citation:

---

Envoyé par kango

Là encore, je perçois le "this" comme une exception: il y a une règle qui tend à ne pas avoir à l'employer mais bon parfois il le faut parce qu'on peut pas faire autrement. La présence, répétée et pénible de self selon toi, permet à mon sens une cohérence bien meilleure.

---

Je ne suis pas fan de la mode du "this" implicite, en particulier en Java où l'on ne fait pas portée au nom de la variable son caractère membre (_nom, m_nom)...

Il reste qu'être forcer de passer "self" en argument m'évoque plus une proximité avec les mécanismes d'interprétation, que de la P.O.O. reposant sur des classes... (A vrai dire, je pense que ca simplifie juste la vie de l'interpréteur Python au niveau des appels de fonctions, mais pas celle du développeur qui utiliserait que rarement un équivalent de "static"... Ou alors, this n'a pas été posé au départ dans la liste des mots clés réservé dès la naissance de Python?)

Citation:

---

Envoyé par kango

Je suis d'accord sur les interfaces. Même si plusieurs librairies implémentent des notions parfois un peu différentes (la zca, PyProtocols) j'aimerais vraiment les voir débarquer dans la librairie standard. Donc rien ne nous empêche d'utiliser des interfaces en Python. Je les utilise au quotidien. C'est un outil extrêmement puissant, peut être encore plus en Python du fait de son typage dynamique et de l'héritage multiple par exemple ;) (je parle du fameux duck typing). Le modèle objet de Python (soit disant pas bon) permet d'implémenter facilement cette notion d'interface. De l'autre côté, certains peinent avec l'héritage multiple ;). Je trouve même que la notion d'interface en Python dépasse celle de Java par exemple, dans le sens où en Java, on se défend souvent de l'héritage multiple en prétextant les interfaces. En Python, on a les deux, et moi, j'aime ça.

---

Pardon pour la contre vérité, j'ai été rebuté avant de les trouver :oops: Je n'entrerai pas dans le débat sur le typage dynamique et l'intérêt de permettre à un développeur implémentant une interface de savoir quel "type" il peut ou doit renvoyer, c'est un autre débat ;) Je suis tantôt favorable, tantôt défavorable en fonction de la "taille" et de la complexité du projet... J'apprécie le compromis en PHP où il est possible de spécifier ou non une interface qui doit être respectée pour un argument de fonction...

Citation:

---

hmm, absence de mots clés en Python ou abondance injustifiée dans d'autres ? On peut tout à fait choisir de faire de très longues phrases pour exprimer une idée simple qui ne nécessite que quelques mots. La concision n'est pas un signe de défaillance intellectuelle mais une qualité. Mais je comprends que pour expliquer certains détails superflus, on puisse avoir besoin d'inventer des mots :D

---

Quand les systèmes deviennent complexes, il devient intéressant de préciser au développeur certaines informations et de l'empêcher à tout prix de faire des boulettes... En temps qu'utilisateur d'une bibliothèque, je trouve appréciable que l'on m'interdise de faire des boulettes et que ces boulettes correspondent à des erreurs de syntaxes plutôt qu'à des erreurs d'exécutions...
Sans cela, pour gagner quelques frappes de clavier, on contraint le développeur à se plonger dans la documentation et à être prudent dans l'utilisation des classes qu'on lui fourni.


Mais Python n'a pas à rougir de l'absence de ces mots clés qui permettent aux développeurs de blinder l'utilisation des classes qu'ils développent... Ces considération sur du même ordre que la présence ou non de la déclaration types. Quand on utilise un langage de script, bien souvent, c'est pour s'en affranchir car on n'a pas besoin d'autant d'une sécurité qui allonge les lignes de code.

Citation:

---

euh.. quel rapport ? On a aussi Qt en Python Et Python est encore plus concis avec ça :p (mais où s'arrêtera t'il !)

---

Je sais, j'ai vu... La critique était plutôt à l'encontre de C++ où la souplesse n'est pas le mot clés ;) Qt apporte un peu de douceur et des éléments permettant d'amener entre autre un typage plus léger avec la classe QVariant par exemple.

Citation:

---

Python souffre je pense du fait qu'il ne soit pas encore enseigné à grande échelle dans les écoles ou les universités (comparativement à Java ou C++ éventuellement). Dés lors, une grande partie de la population considère que la référence c'est Java ou C++ et qu'il "manque" des choses à Python

---

Il "manque" des choses à tous les langages et dans bien des situations, je préfère utiliser un langage de script comme Python à un langage comme Java ou C++...

La critique n'est pas un troller sur les bienfaits de Java face à Python en général... Il y a bien des cas où le contexte de développement fait que je préfère les "défauts" de Python à ceux de Java.

Le modèle objet de Java est plus complet, au sens où il colle plus à l'objet au sens de l'OMG (Object Management Group, UML). On apprend plus de chose sur la P.O.O. en apprenant Java; qu'en essayant d'apprendre la P.O.O. dans Python ou C++ qui l'ajoute en surcouche.

Voir par exemple un cour comme celui-ci du lien ci-dessous et comprendre pourquoi Java sert de support à la présentation de la P.O.O. dans les cursus ;)

http://perso.telecom-paristech.fr/~c...ava/index.html

beaucoup de bon sens dans ce que tu dis, je jetterai un oeil à ton dernier lien :)

Citation:

---

Envoyé par wiztricks

Truc plus court...
Le fait est que les langage "statiques" n'ont pas d'autre choix que de passer par l'héritage (ou l'interface) pour réaliser cela alors qu'en "dynamique", la "réflexion" fait disparaître le problème.

---

Ce n'est pas plutôt la question de résoudre l'adresse d'une fonction à l'exécution ou à la "compilation"?

Java quand bien même il y a compilation, est un langage interprété plutôt "dynamique"... En particulier, on peut charger les classes dynamiquement. Java, C# et autre langage à machine virtuelle ont des mécanismes d'exécutions sensiblement proche de ceux des langages de script : C'est ce qui fait leurs forces sur C++...

C'est ce qu'apporte Qt en C++, une souplesse à l'exécution : de la réflexion, de l'introspection et des signaux...

Citation:

---

Envoyé par wiztricks

Par exemple, si on écrit une fonction carré, style:
def carré(x):
return x * x
Nous pourrons l'appliquer indifféremment à des float, int, ... ou à n'importe quel objet pour lequel l'opération * a un sens.

---

Le fond est de savoir si l'on accepte que le contrôle du "a un sens" se passe à l'exécution... Sans ça, on passe par des interfaces pour pouvoir contrôler la bonne implémentation des "prérequis".

Ensuite, si les concepteurs de Java le voulait, ils introduiraient les fonctions magiques pour la surcharge des opérateurs. Là encore, je pense que c'est un en partie un choix de rigueur en matière de conception objet pour rester conforme à ce qui sort de l'OMG. La surcharge des opérateurs s'apparente à des fonctions libres qui n'ont pas leurs places dans un monde objet pur.

Seul les quelques types primitifs qui servent de base à la définition des objets en bénéficie ce qui est cohérent avec l'esprit de Java.

C++ n'a pas ce problème car il est multi-paradygme assumé. On y fait même cette fonction "carree" à coup de template et de surcharges d'opérateurs avec un contrôle à la compilation...

On y ajoute sans trop de mal un type "var" qui permet d'écrire la chose suivante :

Code:

---

1 2 3 4

var x = 3; var y = "toto"; var r = x*y; // r vaut "totototototo"

---

Mais bon, ca n'est pas trop dans l'esprit du standard :aie:

Citation:

---

Envoyé par wiztricks

Ceci dit, il est vrai que Python manque de 'verbes' pour accroître contrôle et précision mais c'est plus côté ajout d'abstractions aux objets que pour se rapprocher des langages statiques.

---

En même temps, c'est normal car amené la sécurité amène la complexité. Après, chacun ses goûts et besoin en la matière :mrgreen:

Citation:

---

est-ce le fait qu'elle soit instanciable néanmoins (rien n'empêche d'instancier un objet de type Humain) et que cette instance soit inutilisable qui pose problème selon toi ?

---

Oui c'est exactement ce qui me pose un problème.

Citation:

---

Et je ne défends pas du tout le mythe du langage universel, ce serait idiot vu le nombre de librairies Python que j'utilise tous les jours et qui sont codées en C, C++ ou Fortran

---

Je ne pensais pas du tout à toi, mais plutôt à:

Citation:

---

Envoyé par afranck64

Et la vous faites un peu peur car j ai toujours pense que le python serait mon arme ultime pour les codes.

---

donc à essayer de déciller les yeux de afranck64 en lui disant tout de go qu'il ne trouvera jamais ce qu'il cherche ni ici ni ailleurs.

Bonjour,

en fait quand je disais mon "arme ultime contre les codes" je voulais juste dire qu en 1 semaine il y a un tas de belles chose que je peux faire avec python alors qu avec les autres langages ... je ne peux pas causer anglais avec ma machine.

:mouarf:

Citation:

---

je voulais juste dire qu en 1 semaine il y a un tas de belles chose que je peux faire avec python alors qu avec les autres langages ..

---

C'est le côté vraiment sympa de python. Retour sur investissement maximum.

Citation:

---

essayer de dessiller les yeux de afranck64 en lui disant tout de go qu'il ne trouvera jamais ce qu'il cherche ni ici ni ailleurs.

---

Pas grave:

Citation:

---

Ce qu'on trouve est plus important que ce qu'on cherche.

---

:P

Salut,
Juste pour vous faire partager cette présentation des implications du duck typing sur le style de programmation.
- W

Juste une remarque en passant. Ca m'etonne qu'on ait peu parlé des descripteurs sur ce sujet.

Dans 'Thinking in java' de Eckel, on nous raconte qu'une vraie POO est censée utiliser une méthode set() et une méthode get() pour chaque attribut. Cela permet de s'assurer que l'objet puisse faire évoluer son implémentation interne sans que le code utilisateur soit perturbé.

Or en python, il est possible de faire cela directement sur les membres. De ce point de vue il me semble que Python pousse un cran plus loin le concept d'objet (si l'on entends la POO comme moyen de structurer un code, de séparer les taches, plutôt que comme une syntaxe de programmation)

Citation:

---

Envoyé par VV33D

Or en python, il est possible de faire cela directement sur les membres. De ce point de vue il me semble que Python pousse un cran plus loin le concept d'objet (si l'on entends la POO comme moyen de structurer un code, de séparer les taches, plutôt que comme une syntaxe de programmation)

---

Qu'entendez vous par "sur les membres"?
- W

Citation:

---

Qu'entendez vous par "sur les membres"?

---

Il doit sous-entendre qu’en Python, on programme droit sur ses jambes, ou en acrobate sur les bras pour les plus doués,
et qu’en C++ et Java on programme sur les genoux.

J'entendais membre comme synonyme d' attribut

Citation:

---

Il doit sous-entendre qu’en Python, on programme droit sur ses jambes

---

Bah oui ca fait peur les serpents :lol:

En python les properties permettent d'accéder aux setters/getter/... comme s'il s'agissait d'attributs "normaux". A ce niveau, c'est plus une question de style: u = o.attr plutôt que o.get_attr()
Mais l'effet est identique l'API get/set "cache" l'implémentation et permet de la revoir sans embêter les clients.

Moi j'aime bien jouer avec en dynamique... L'attribut attr est remplacé par la property "attr" qui stocke éventuellement les valeurs dans '_attr'.
- W