Classe-Définir un attribut via une chaîne

Bonjour.

Soit le code suivant.

Code:

---

1 2 3

class bidon() def __init__(self): ...

---

Je voudrais ajouter l'attribut bidon.test en utilisant la chaîne "test". Ceci me permettrait d'ajouter des attributs et leurs valeurs définies à partir d'un dictionnaire.

bonjour,

c'est pour ajouter un attribut d'instance ou un attribut de classe ?

pour la classe:

Code:

---

bidon.__dict__[chaine] = valeur

---

pour l'instance:

Code:

---

1 2	b = bidon() b.__dict__[chaine] = valeur

---

ou alors danxs l'init de la classe ?

Code:

---

1 2	def __init__(self): self.__dict__[chaine] = value

---

ou encore, la même chose mais en utilisant setattr:

Code:

---

1 2 3 4

setattr(bidon,chaine,value) setattr(b,chaine,value) setattr(self,chaine,value)

---

Salut
J'ai peut être pas tout compris mais 'Folder' ci dessous fait un peu cela.

Code:

---

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

class Folder(dict): def __init__(self, **kwds): super(Folder, self).__init__(kwds) self.__dict__ = self   if __name__ == '__main__': c = Folder(a=1, b='abc') print 'c= ', c print 'c.a =', c.a print 'c.b =', c.b c.c = '123' print 'c = ',c

---

- W

Bonjour,

Peut-être suis-je à côté de la question, mais tant pis:

Python accepte qu'on crée un nouvel attribut de classe 'à la volée', et pourquoi pas, un attribut qui soit un dictionnaire.

Code:

---

1 2 3 4 5 6 7 8 9

class Truc(object): pass   a = Truc() a.test = {} a.test['x'] = 123456 print a.test['x'] 123456

---

J'avoue que cette facilité m'a toujours un peu choqué. Mais bon. Pour une fois que c'est utile...:roll:

Tyrtamos

Citation:

---

Envoyé par tyrtamos

J'avoue que cette facilité m'a toujours un peu choqué.

---

moi de même. mais j'avoue avoir lu un article sur le data driven programming dans le dernier HS Linux Mag sur Python qui m'a presque convaincu :)

(je n'ai pas le mag sous les yeux, je ne me souviens plus du nom de l'auteur)

Salut Tyrtamos,

Citation:

---

Envoyé par tyrtamos

Python accepte qu'on crée un nouvel attribut de classe 'à la volée', et pourquoi pas, un attribut qui soit un dictionnaire

---

Dans le cas particulier, il s'agit d'un attribut d'instance et non de classe: mais on peut les créer aussi 'à la volée' ou via setattr si on doit transformer une chaine de caractères en noms de variable.

Citation:

---

J'avoue que cette facilité m'a toujours un peu choqué. Mais bon. Pour une fois que c'est utile...:roll:

---

Heu?!? C'est quand même ce qui contribue au "dynamique" du langage.
On peut même ajouter ou remplacer des méthodes... Ce qui peut être bien sympa lorsqu'on teste.
Note: __slots__ permet de restreindre quelque peu les ajouts de variables
- W

Bonjour wiztricks,

Citation:

---

Envoyé par wiztricks

Heu?!? C'est quand même ce qui contribue au "dynamique" du langage.

---

Mais le basic avait aussi cette souplesse-là: une faute de frappe et hop: une nouvelle variable est crée sans rien dire... Désolé, je supporte, mais je ne mets pas ça dans les qualités...

Pour ma défense, j'ai beaucoup travaillé en Pascal: j'ai donc été élevé "à la dure", et il doit m'en rester quelques séquelles. :D.

Tyrtamos

Merci pour ces réponses.

Ce que je cherchais est dans ce code.

Code:

---

1 2	b = bidon() b.__dict__[chaine] = valeur

---

Pour rebondir sur le dynamisme de Python, il est parfois dangereux. Il y a a peu j'ai testé des snippets pour pyenchant. Et hop, je me retrouve avec ce que je crois être un gros bug. Je décide de réfléchir au problème, et un peu fatigué je me passe la tête sous l'eau. Et là, révélation, le bug est sous mes yeux dans le mirroir : c'était moi qui avais nommé un fichier tokenize.py alors que pyenchant utilise un module nommé tokenize.
Un petit message pour me dire "Attention, vous avez redéfini tokenize." serait bienvenu. Non ?

Au passage, peut-on créer une sécurité dans un module que l'on tape pour repérer le type de faute que j'ai commise ?

Citation:

---

Envoyé par rambc

Au passage, peut-on créer une sécurité dans un module que l'on tape pour repérer le type de faute que j'ai commise ?

---

Ben un minimum est d'utiliser pylint ou des IDE tels qu'Eclipse ou Netbeans qui font pas mal de vérifications y compris la complétion des routines appelées.
- W

En fait je cherche une solution en amont que je coderais dans mon module pour prévenir l'utilisateur qu'il a utilisé un nom dont mon module a besoin.

Salut,

j'avais d'abord penser à un wrapper à placer sur le __dict__ du module, mais pas probant : ce __dict__ n'est pas dispo à l'intérieur du module, à moins de faire beaucoup (trop de) boulot:

Code:

---

1 2 3 4 5

from sys import modules pname = globals()['__name__'] parent = modules[pname] print parent.__dict__

---

Ca me parait trop compliqué...
Je rejoins wiztricks, utiliser pylint, et même de façon idéale lancer l'exécution de pylint automatiquement lorsque l'on lance les tests (encore faut-il tester ^^).

Je rejoins complètement tyrtamos et kango pour ce qui concerne la création d'attributs de classe 'à la volée'. C'est presque contraire aux fondements de la P.O.O. puisque les objets d'une même classe ne sont pas égaux. Cela m'a également choqué mais il a dû m'arriver une fois ou deux d'en tirer parti (sans gloire).

Citation:

---

Envoyé par Zavonen

C'est presque contraire aux fondements de la P.O.O.

---

Quels fondements ?
Si je m'en réfère à Wikipedia, la POO est un concept élaboré par Alan Kay, qui est aussi le concepteur de Smalltalk, langage qui en + d'être orienté objet est un des langages les + dynamiques qui soient.

Le principe d'égalité d'instances d'une même classe me semble venir d'une certaine approche de la POO (je dirais la POO statique, à la Java).
Dans l'idéologie Python, la nature des objets qu'on manipule importe peu, du moment qu'ils font ce qu'on leur demande.
Dès lors, ça ne devrait pas choquer d'avoir des objets qui sont "+ égaux" que d'autres.

Ce qui peut faire peur, c'est cette liberté qui autorise tout et n'importe quoi, mais à chacun de prendre ses responsabilités.

Citation:

---

Envoyé par nardo47

Ca me parait trop compliqué...
Je rejoins wiztricks, utiliser pylint, et même de façon idéale lancer l'exécution de pylint automatiquement lorsque l'on lance les tests (encore faut-il tester ^^).

---

En fait, mon idée était un peu conne car si quelqu'un utilise mon projet et y ajoute un module, c'est a priori qu'il programme en Python, enfin je l'espère... :mouarf: Du coup, les remarques sur pylint et autres sont bien vues.

Citation:

---

Le principe d'égalité d'instances d'une même classe

---

Je ne vois pas ce que tu veux dire par principe d'égalité, peux-tu m'expliquer s'il te plaît?

Citation:

---

Je rejoins complètement tyrtamos et kango pour ce qui concerne la création d'attributs de classe 'à la volée'

---

Modifier un attribut de classe ou créer un attribut de classe à la volée, c'est pas la même chose? L'attribut existe ou existera non?

Code:

---

1 2	def __init__(self): self.__dict__[chaine] = value

---

Personnellement je n'ai jamais vu ce type de notation, je trouve ça assez déroutant.

Citation:

---

Envoyé par fred1599

Je ne vois pas ce que tu veux dire par principe d'égalité, peux-tu m'expliquer s'il te plaît?

---

Je paraphrasais Zavonen qui voulait dire (il me corrigera si je me trompe) que 2 instances d'une même classe doivent avoir exactement les mêmes attributs (au sens large, donc propriétés, méthodes, etc).
En théorie, je suis d'accord avec le principe, appelé le principe de moindre surprise.
Après, vaut-il mieux interdire quelque chose dans un langage ou laisser la responsabilité au codeur de ne pas abuser de ce quelque chose, chacun son choix.

Citation:

---

Envoyé par fred1599

Modifier un attribut de classe ou créer un attribut de classe à la volée, c'est pas la même chose? L'attribut existe ou existera non?

---

Sauf que quand tu crées un attribut à la volée, tu le crées le + souvent sur une seule instance d'une classe.

Code:

---

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

>>> class Spam(object): pass >>> a = Spam() >>> b = Spam() >>> a.spam = 12 >>> a.spam 12 >>> b.spam --------------------------------------------------------------------------- AttributeError Traceback (most recent call last) ... AttributeError: 'Spam' object has no attribute 'spam'

---

Cela dit, maintenant que j'y pense, on peut aussi ajouter un attribut de classe, qui sera donc dispo pour toutes les instances de cette classe, y compris celle qui ont déjà été instanciées.

Code:

---

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

>>> class Spam(object): pass >>> a = Spam() >>> b = Spam() >>> Spam.spam = 12 >>> a.spam 12 >>> b.spam 12 >>> a.spam = 42 >>> a.spam 42 >>> b.spam 12

---

Citation:

---

Envoyé par fred1599

Code:

---

1 2	def __init__(self): self.__dict__[chaine] = value

---

Personnellement je n'ai jamais vu ce type de notation, je trouve ça assez déroutant.

---

Comme tout chose que l'on ne connaît pas :

• la boucle for en C ;
• les compréhensions de listes ;
• les générateurs et l'expression yield ;
• les closures ;
• les fonctions anonymes ;
• le passage par référence ;
• pas mal de design patterns ;
• pleins d'autres choses.

Tout est question d'habitude, voire de convention.

Citation:

---

Je paraphrasais Zavonen qui voulait dire (il me corrigera si je me trompe) que 2 instances d'une même classe doivent avoir exactement les mêmes attributs (au sens large, donc propriétés, méthodes, etc).

---

C'est exactement ce que je voulais dire. Pas de démenti donc.

Citation:

---

un peu fatigué je me passe la tête sous l'eau. Et là, révélation, le bug est sous mes yeux dans le mirroir : c'était moi qui avais nommé un fichier tokenize.py

---

ouah, quel art de la narration !

L’orthographe, c’est moins ça.

Citation:

---

Envoyé par tyrtamos

J'avoue que cette facilité m'a toujours un peu choqué. Mais bon. Pour une fois que c'est utile...:roll:

---

Citation:

---

Envoyé par kango

moi de même. mais j'avoue avoir lu un article sur le data driven programming dans le dernier HS Linux Mag sur Python qui m'a presque convaincu :)

---

Citation:

---

Envoyé par Zavonen

Je rejoins complètement tyrtamos et kango pour ce qui concerne la création d'attributs de classe 'à la volée'. C'est presque contraire aux fondements de la P.O.O. puisque les objets d'une même classe ne sont pas égaux. Cela m'a également choqué mais il a dû m'arriver une fois ou deux d'en tirer parti (sans gloire).

---

Je distingue deux ordres de critique dans ces propos:
- c’est choquant
- c’est inutile




Je ne comprends pas qu’on puisse trouver choquante cette possibilité. J’avoue qu’au début, je l’ai trouvé légèrement surprenante. Mais j’ai rapidement considéré que je devais intégrer cette information au même titre que plein d’autres qui constituent le langage, faisant aux confiance développeurs du langage pour savoir ce qu’il font.



Si je comprends bien tyrtamos, ce qui le choque est que Python laisse la possibilité au programmeur de faire des bêtises.
Je pense que la quantité de risques courus est proportionnelle aux possibilités. Augmenter la sécurité, c'est en restreignant les possibilités, ce serait brimer la liberté
Chacun a sa réaction face à la problématique. Celle-ci en est une autre:

Citation:

---

Envoyé par nardo47

Ce qui peut faire peur, c'est cette liberté qui autorise tout et n'importe quoi, mais à chacun de prendre ses responsabilités.

---

Pour ma part, je n’ai pas d’avis général, mais sur la définition d’attributs à la volée, je trouverais dommage et pour tout dire incompréhensible, de ne pas disposer de cette possibilité.

Après tout, qui, en voyant ceci:

Code:

---

1 2 3 4 5

lune phobos patisserie 1800 ====================== lune phobos patisserie 1800

---

est capable de dire que ça a été obtenu par

Code:

---

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

class A: st = 'lune' def __init__(self,x): self.ixe = x   a = A('phobos') print A.st,a.ixe   A.st,a.ixe = 'patisserie',1800 print A.st,a.ixe   print '======================'   class A: pass   a = A() A.st,a.ixe = 'lune','phobos' print A.st,a.ixe   A.st,a.ixe = 'patisserie',1800 print A.st,a.ixe

---

Comme l’a écrit wiztricks, __slots__ permet de prévenir des erreurs d’écriture du genre a.jxe = 90 qui créerait par erreur un attribut jxe au lieu de modifier ixe.
On peut aussi se faire sa gendarmerie personnelle en employant __setattr__()

Python ne manque pas de possibilités. Personnellement, tant que j’ai le sentiment de pouvoir progresser toujours plus en Python et de pouvoir maitriser de mieux en mieux les pièges possibles, je préfère avoir à ma disposition de nombreuses possibilités.



Ça revient à dire idem que:

Citation:

---

Envoyé par wiztricks

C'est quand même ce qui contribue au "dynamique" du langage.

---

Le data driven programming évoqué par kango en est un exemple.

J’en ai un autre, bien que je ne comprenne pas tout:

Citation:

---

Not many are aware of this feature, but Python's functions (and methods) can have attributes.
http://stackoverflow.com/questions/3...ses-and-abuses

Here are some examples of what you can do with this feature.
http://www.python.org/dev/peps/pep-0232/

cf
http://mail.python.org/pipermail/pyt...il/003364.html

---

Ce qui répond au pseudo-argument d’inutilité.









Pour ce qui est de l’autre argument de Zavonen pour trouver choquante cette possibilité, je réagis comme

Citation:

---

Envoyé par nardo47

Citation:

---

Envoyé par Zavonen
C'est presque contraire aux fondements de la P.O.O.

---

Quels fondements ?

---

Citation:

---

Envoyé par fred1599

Citation:

---

Le principe d'égalité d'instances d'une même classe

---

Je ne vois pas ce que tu veux dire par principe d'égalité, peux-tu m'expliquer s'il te plaît?

---

Citation:

---

Envoyé par Zavonen

Citation:

---

Je paraphrasais Zavonen qui voulait dire (il me corrigera si je me trompe) que 2 instances d'une même classe doivent avoir exactement les mêmes attributs (au sens large, donc propriétés, méthodes, etc).

---

C'est exactement ce que je voulais dire. Pas de démenti donc.

---

Pourquoi « doivent avoir exactement les mêmes attributs » ?!?

Je trouve rudement bizarre de reprocher à Python de doter les objets d’une “feature“ qui ne peut qu’accroître la souplesse de leur utilisation dans un paradigme PO.

Citation:

---

Envoyé par kango

(je n'ai pas le mag sous les yeux, je ne me souviens plus du nom de l'auteur)

---

Python, le serpent très dynamique.
Jean Gabès
Hors-série Linux Magazine no 49 - Août-septembre 2010

Citation:

---

Envoyé par fred1599

Code:

---

1 2	def __init__(self): self.__dict__[chaine] = value

---

Personnellement je n'ai jamais vu ce type de notation, je trouve ça assez déroutant.

---

Il va falloir t’y faire. Car Python fonctionne (on me corrigera si je me trompe) sur la base d’espaces de noms dans tous les sens: les espaces de noms sont implémentés comme des dictionnaires, et Python passe son temps à créer des espaces de noms attachés à certaines catégories Python (module, classe, fonction, en-tête de boucle for, instances de classes, etc...) , à inscrire et désinscrire des items dans ces espaces de noms, et à détruire des espaces de noms (par exemple en sortant d’une fonction).

L’inscription dans un espace de noms consiste à
enregistrer le nom d’un objet sous forme de chaîne comme une clé de l’espace de nom
et à y associer (to bind) l’objet correspondant comme valeur de l’espace de nom.

Citation:

---

The following constructs bind names: formal parameters to functions, import statements, class and function definitions (these bind the class or function name in the defining block), and targets that are identifiers if occurring in an assignment, for loop header, in the second position of an except clause header or after as in a with statement. The import statement of the form from ... import * binds all names defined in the imported module, except those beginning with an underscore. This form may only be used at the module level.

A target occurring in a del statement is also considered bound for this purpose (though the actual semantics are to unbind the name).

http://docs.python.org/reference/exe...ng-and-binding

---

L’attribut __dict__ qui permet d’accéder à l’espace de noms d’une entité (classe, fonction, objet, module...) est fort utile à connaître.

La fonction dir() , qui fonctionne différemment selon qu’on lui fournit un argument ou non, et selon que l’argument est un objet ayant une méthode __dir__() ou non) permet d’obtenir la liste des noms des attributs (au sens large: données menbres aussi bien que fonctions) de l’argument.
dir(arg) elle renvoie en quelque sorte arg.__dict__.keys() et est fort utile itou.

Bon j'avais un peu de mal à comprendre ce topic, et c'est vrai que d'habitude en regardant la longueur des posts d'eyquem, je suis fatigué avant de les lire. Mais là je dois avouer que j'ai bu tes "paroles".

Citation:

---

L’attribut __dict__ qui permet d’accéder à l’espace de noms d’une entité (classe, fonction, objet, module...) est fort utile à connaître.

La fonction dir() , qui fonctionne différemment selon qu’on lui fournit un argument ou non, et selon que l’argument est un objet ayant une méthode __dir__() ou non) permet d’obtenir la liste des noms des attributs (au sens large: données menbres aussi bien que fonctions) de l’argument.
dir(arg) elle renvoie en quelque sorte arg.__dict__.keys() et est fort utile itou.

---

J'y pense jamais à ces espaces de nom qui sont très importants.

Salut,

Puisqu'on discute horreurs permises par la programmation dynamique.
Il y a quelques temps je me suis intéressé à la simplification de patterns GOF que permettait Python. Un de ceux là est "State".

En gros, pour représenter l'état d'un objet on lui associe une classe S1, S2, S3, .... qui sont sous-classe d'une classe abstraite A.
L'état est donc mémorisé dans un attribut style self._state = S1(...).

En fonction de... l'état de notre objet doit être changé pour refléter le nouvel état. Classiquement self._state = S2(...) ce qui crée une instance de S2 et libère S1.

Une façon permise par Python et à n'utiliser que si on comprends ce qu'on fait pour 'changer' l'état est de faire: self._state.__class__ = S2

On peut donc "s'amuser" à changer des choses bien plus "tordues" juste parce que le monde python est un __dict__ de __dict__

- W

Salut wiztricks,

je trouve que tu ne vas pas assez loin. Voici la description du pattern State, tel que présenté dans la version française du livre du GOF lui-même (l'emphase est de moi):

Citation:

---

Permet à un objet de modifier son comportement, quand son état interne change. Tout se passera comme si l'objet changeait de classe.

---

En Python, l'objet peut réellement changer de classe, le pattern est donc trivialement:

Code:

---

self.__class__ = S2

---

Passer par un attribut _state et une délégation, c'est juste faire des ronds de jambe au GOF :)

Enfin, pour être plus précis, pour décrire le pattern il faudrait une classe mère (abstraite), qui contient la partie commune à tous les états (ce qui se trouve dans la classe "Context" du pattern, pour l'occasion fusionnée avec la classe abstraite "State"), et plusieurs classes dérivées pour chacun des états.

[EDIT]
Un exemple (un peu tiré par les cheveux, mais qui je l'espère illustre bien le pattern):
Implémentation d'une file de taille fixe:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43

class EmptyQueueError(Exception): pass class FullQueueError(Exception): pass   class Queue(object): def __init__(self, size): self._size = size self._data = [] self.__class__ = EmptyQueue   def add(self, value): self._data.append(value)   def get(self): return self._data.pop(0)   class EmptyQueue(Queue): def add(self, value): Queue.add(self, value) self.__class__ = PartialyFilledQueue   def get(self): raise EmptyQueueError()   class PartialyFilledQueue(Queue): def add(self, value): Queue.add(self, value) if len(self._data) == self._size: self.__class__ = FullQueue   def get(self): value = Queue.get(self) if len(self._data) == 0: self.__class__ = EmptyQueue return value   class FullQueue(Queue): def add(self, value): raise FullQueueError()   def get(self): value = Queue.get(self) self.__class__ = PartialyFilledQueue return value

---

Salut Dividee

Citation:

---

Permet à un objet de modifier son comportement, quand son état interne change.Tout se passera comme si l'objet changeait de classe.

---

Pour ce qui est de changer la classe à la volée: la différence entre self._state.__class__ et self.__class__ n'est que relative.

Si l'ensemble des méthodes (comportement) de l'objet dépendent de son état courant, on peut bien sûr réduire la représentation de la chose aux seules sous classes représentant "l'état". Dans ce cas, plus la peine de passer par un attribut _state....

Mais c'est quand même lié à des cas particulier et donc quelque peu réducteur par rapport à la mise en œuvre du pattern "en général".
- W

très intéressant cet exemple de pattern dividee.

J'avoue avoir encore un peu de mal à bien gérer les changements d'états. Même si comme tu le dis l'exemple est tiré par les cheveux (on aurait facilement pu se passer de cette approche ici), la technique exposée est claire.

On peut également facilement extrapoler cette technique avec l'approche légèrement différente proposée par wiztricks (en déléguant le changement d'état à un attribut de la classe).

wiztricks, j'ai cru comprendre que tu essayais d'adapter certains pattern du GoF à Python. Je me rends assez régulièrement sur cette page:

http://en.wikipedia.org/wiki/Design_...ter_science%29

Certains des patterns ont des exemples Python. J'utilise très fréquemment certains d'entre eux. Je serais curieux de voir les adaptations que tu as faites à moins que ces travaux ne soient pas partageables :)

Salut,

Citation:

---

Envoyé par kango

Certains des patterns ont des exemples Python. J'utilise très fréquemment certains d'entre eux. Je serais curieux de voir les adaptations que tu as faites à moins que ces travaux ne soient pas partageables :)

---

Hélas, cela n'ayant rien de très original - google truc donne des tas d'exemples - je n'ai pas pris la peine de mettre en forme les choses pour que ce soit "lisible".
- W

ok, on ne sait jamais :)

merci quand même

Citation:

---

Envoyé par wiztricks

Si l'ensemble des méthodes (comportement) de l'objet dépendent de son état courant, on peut bien sûr réduire la représentation de la chose aux seules sous classes représentant "l'état". Dans ce cas, plus la peine de passer par un attribut _state....

Mais c'est quand même lié à des cas particulier et donc quelque peu réducteur par rapport à la mise en œuvre du pattern "en général".
- W

---

Je ne pense pas que ce soit réducteur par rapport au pattern. Le comportement qui ne dépend pas de l'état va dans la classe parente. Je pense au contraire que c'est tout à fait dans l'esprit du pattern, une simplification de son implémentation qui exploite le dynamisme de python.

8O

Citation:

---

Envoyé par dividee

Je ne pense pas que ce soit réducteur par rapport au pattern. Le comportement qui ne dépend pas de l'état va dans la classe parente. Je pense au contraire que c'est tout à fait dans l'esprit du pattern, une simplification de son implémentation qui exploite le dynamisme de python.

---

Certes mais lorsqu'on écrit:

Citation:

---

Permet à un objet de modifier son comportement, quand son état interne change. Tout se passera comme si l'objet changeait de classe.

---

Ca signifie que l'appelant reçoit un objet O dont le comportement change comme si l'objet changeait de classe.
Et le "comme si" en bon français signifie qu'il n'en change pas.

A défaut, on change l'interface...

Et ce faisant on parle d'autre chose que du pattern State - ce n'est pas interdit - juste que les informaticiens souffrent trop d'un manque d'abstractions partagées pour qu'on puisse se permettre de gribouiller les rares que nous pourrions avoir.

Ce qui ont le temps pourraient lire un article de A.Martelli & C° sur un sujet similaire
- W

J’aimerais bien savoir ce que ça veut dire « changer de classe »

Citation:

---

Envoyé par eyquem

J’aimerais bien savoir ce que ça veut dire « changer de classe »

---

Imaginons que notre objet "o" soit de la classe Commande et que nos états soient EnCours, Livré, ...
Si on applique ce que propose Dividee, la classe de "o" sera EnCours, Livrée,... une fonction de l'état et non plus "Commande".

Ce n'est pas grave: on pourrait documenter les différentes valeurs retournées par type(o) dans ce cas, ou n'utiliser qu'isinstance (..., Commande) ou fournir un is_commande qui fait ce qu'il faut.

- W

Citation:

---

Envoyé par wiztricks

Ca signifie que l'appelant reçoit un objet O dont le comportement change comme si l'objet changeait de classe.
Et le "comme si" en bon français signifie qu'il n'en change pas.

---

J'ai parlé de l'esprit du pattern, pas de la lettre. C'est évident qu'ils n'allaient pas écrire que l'objet changeait de classe, vu que ce n'est pas concevable dans le modèle orienté objet classique (statiquement typé) sur lequel le GOF se base. Mais ce pattern existe justement, à mon sens, pour contourner cette limitation. Limitation qui n'existe pas en python. Il n'y a donc rien à contourner.

Citation:

---

Et ce faisant on parle d'autre chose que du pattern State - ce n'est pas interdit - juste que les informaticiens souffrent trop d'un manque d'abstractions partagées pour qu'on puisse se permettre de gribouiller les rares que nous pourrions avoir.

---

Le pattern se réduit à si peu de chose en Python qu'on pourrait lui disputer le statut de design pattern, mais il me semble que c'est un technique assez peu connue qui mérite donc quand-même qu'on lui donne un nom et un statut. Appliquer le State Pattern à la lettre en Python me semble lourd et malvenu.

Mais je sais que les patterns ont aussi une vocation de communication (abstraction partagée) et je comprends donc ton souci de donner à cette technique le nom de State Pattern.

Citation:

---

Ce qui ont le temps pourraient lire un article de A.Martelli & C° sur un sujet similaire

---

Merci pour le lien, je lirais l'article dès que j'ai le temps.

Citation:

---

Imaginons que notre objet "o" soit de la classe Commande et que nos états soient EnCours, Livré, ...
Si on applique ce que propose Dividee, la classe de "o" sera EnCours, Livrée,... une fonction de l'état et non plus "Commande".

---

Petit détail, j'aurais appelé les sous-classes "CommandeEnCours", "CommandeLivrée", ... pour qu'il soit bien apparent que ce bien toujours des Commandes. C'est bien la sémantique de l'héritage; une instance d'une sous-classe est aussi un instance de toutes ses super-classes. La classe effective change, mais ça reste une Commande.

Citation:

---

Ce n'est pas grave: on pourrait documenter les différentes valeurs retournées par type(o) dans ce cas, ou n'utiliser qu'isinstance (..., Commande) ou fournir un is_commande qui fait ce qu'il faut.

---

Je ne suis pas sûr de bien suivre. L'utilisateur n'a que la classe Commande à connaître, les sous-classes ne font pas partie de l'interface. C'est vrai que les sous-classes vont "leaker" (être visibles côté client), mais en Python, on n'est pas à ça près (il n'y a de toute façon pas de concept d'interface dans le langage, tous les attributs sont publics, etc.).
C'est effectivement isinstance qu'il faut utiliser s'il faut distinguer le type Commande d'autres types (c'est pas pour rien que type(o) == Commande c'est "beurk"), mais je ne vois pas ce qui aurait pu être grave mais ne l'est pas grâce à cela.

Citation:

---

Envoyé par dividee

J'ai parlé de l'esprit du pattern, pas de la lettre. ....Il n'y a donc rien à contourner.

---

Regardes le pattern "Template method", il propose une réalisation de changement de comportement "par héritage" similaire à la tienne.
Le pattern "State" propose lui une réalisation "par délégation".

Il n'y a pas - sur ce point - de "limitation" qui empêcheraient les langages "compilés" de réaliser ce type de liaison "par héritage" : les contextes, l'histoire qu'on raconte sont différentes ainsi que la réalisation proposée en illustration de solution.

Citation:

---

Le pattern se réduit à si peu de chose en Python qu'on pourrait lui disputer le statut de design pattern...

---

J'étais tombé sur une présentation sur les patterns GOF en Python faite par Martelli ou Simonetto à l'occasion d'un PyCon... Je n'arrive pas à remettre la main dessus mais çà raconte à peu près la même chose: en Python, la réalisation de nombre de patterns peuvent se faire avec Template method.

Mais nous retrouvons quand même l'interrogation qui nous a amené ici: est ce que le "techniquement possible" suffit à rendre acceptable certaines pratiques?

Citation:

---

Mais je sais que les patterns ont aussi une vocation de communication (abstraction partagée)

---

Absolument! Et la réduction de nombre de patterns de conception au seul pattern Template method, nous fait perdre des capacités de nuances et de précision nécessaires à la conception de codes complexes et indispensables à la réalisation de codes maintenables.

Hélas, la richesse de ces abstractions ne peut être appréciée de façon tangible que lorsqu'on doit communiquer avec une certaine précision et devoir s'amuser à contrôler que les rendus répondent aux attentes.

Ce qui suppose des projets conséquents côté taille des équipes, durée,...
Les Pythonistes étant plutôt "cow-boys" sont rarement confrontés à ce genre de phénomènes.

- W

Et moi qui pensais poser une question à la con... :mouarf: