Lors d'une formation à CPS que j'ai pris à la volée, on m'a parlé de
"patches de classes".
Moi les seuls patches informatiques que je connais sont ceux qu'on génère
avec la commande "diff -u" et qu'on applique avec "patch" (sous Unix).
Manifestement, on peut patcher des classes.
J'ai un peu essayé de chercher hein, mais chercher avec "patch python" ne
sert à rien sur le net, et je ne vois pas comment je peux affiner les
resultats.
Pourriez-vous m'apprendre ce que sont ces "nouveaux" genre de patches,
s'il vous plait? Merci.
Lors d'une formation à CPS que j'ai pris à la volée, on m'a parlé de "patches de classes".
Moi les seuls patches informatiques que je connais sont ceux qu'on génère avec la commande "diff -u" et qu'on applique avec "patch" (sous Unix).
Manifestement, on peut patcher des classes.
J'ai un peu essayé de chercher hein, mais chercher avec "patch python" ne sert à rien sur le net, et je ne vois pas comment je peux affiner les resultats. Pourriez-vous m'apprendre ce que sont ces "nouveaux" genre de patches, s'il vous plait? Merci.
Très rapidement: en Python tout est dynamique. Une classe est un objet, et tu peux ajouter/redéfinir des méthodes à l'exécution.
Fait des dir() sur tes classes pour avoir plus d'informations, et cherche plutôt du côté Python+introspection
Lors d'une formation à CPS que j'ai pris à la volée, on m'a parlé de
"patches de classes".
Moi les seuls patches informatiques que je connais sont ceux qu'on génère
avec la commande "diff -u" et qu'on applique avec "patch" (sous Unix).
Manifestement, on peut patcher des classes.
J'ai un peu essayé de chercher hein, mais chercher avec "patch python" ne
sert à rien sur le net, et je ne vois pas comment je peux affiner les
resultats.
Pourriez-vous m'apprendre ce que sont ces "nouveaux" genre de patches,
s'il vous plait? Merci.
Très rapidement: en Python tout est dynamique. Une classe est un objet, et
tu peux ajouter/redéfinir des méthodes à l'exécution.
Fait des dir() sur tes classes pour avoir plus d'informations, et cherche
plutôt du côté Python+introspection
Lors d'une formation à CPS que j'ai pris à la volée, on m'a parlé de "patches de classes".
Moi les seuls patches informatiques que je connais sont ceux qu'on génère avec la commande "diff -u" et qu'on applique avec "patch" (sous Unix).
Manifestement, on peut patcher des classes.
J'ai un peu essayé de chercher hein, mais chercher avec "patch python" ne sert à rien sur le net, et je ne vois pas comment je peux affiner les resultats. Pourriez-vous m'apprendre ce que sont ces "nouveaux" genre de patches, s'il vous plait? Merci.
Très rapidement: en Python tout est dynamique. Une classe est un objet, et tu peux ajouter/redéfinir des méthodes à l'exécution.
Fait des dir() sur tes classes pour avoir plus d'informations, et cherche plutôt du côté Python+introspection
En Python, une classe est un objet (structuré) modifiable. La particularité, c'est qu'une classe est instanciable. Du coup, on peut distinguer les modifications apportées à la classe, ou à une instance de la classe.
On pourrait aussi gloser sur l'impact de l'héritage, mais, bon, pourquoi ne pas débattre du sexe des anges ?
@-salutations
Michel Claveau
Bonjour !
En fait, c'est le terme "patch" qui me gêne.
En Python, une classe est un objet (structuré) modifiable. La particularité,
c'est qu'une classe est instanciable. Du coup, on peut distinguer les
modifications apportées à la classe, ou à une instance de la classe.
On pourrait aussi gloser sur l'impact de l'héritage, mais, bon, pourquoi ne
pas débattre du sexe des anges ?
En Python, une classe est un objet (structuré) modifiable. La particularité, c'est qu'une classe est instanciable. Du coup, on peut distinguer les modifications apportées à la classe, ou à une instance de la classe.
On pourrait aussi gloser sur l'impact de l'héritage, mais, bon, pourquoi ne pas débattre du sexe des anges ?
@-salutations
Michel Claveau
Hervé Cauwelier
Bonjour,
Lors d'une formation à CPS que j'ai pris à la volée, on m'a parlé de "patches de classes".
Halala... éléver les techniques de goret au rang de méthode de programmation...
Il y a deux problèmes. Le premier est que c'est une technique spécifique à Zope car spécifique à ses problèmes, qu'on appelle un « monkey patch. » Le fait est que les instances de classe sont persistantes et c'est la merde pour les faire évoluer ou les remplacer par une instance d'une autre classe, même si elle hérite de la classe d'origine.
Parce que, et j'insiste bien dessus, la meilleure méthode en programmation objet et est reste d'hériter de la classe qu'on veut surcharger et de charger les données pour créer un objet de cette nouvelle classe, compatible avec l'ancien format. Mais c'est mort avec Zope...
L'idée est alors d'aller attaquer directement la classe originale que Zope charge au démarrage en changeant à la volée ses attributs et classes, pour que les siens soient appelés à la place.
Puisqu'il s'agissait d'une formation CPS (hello Damien), il y a longtemps qu'on aurait dû faire nos tools qui héritent de ceux de CMF, au lieu de les patcher. Sauf que maintenant, il faudrait écrire des scripts longs comme le bras pour migrer l'existant. Ils ont fini par faire leur CPSUserFolder mais sans toucher aux instances existantes. Un gros besoin serait un CPSCatalogTool qui intégrerait tous les monkey patchs. De ce que j'ai vu de Plone, ils ont déjà leur version Plone des outils CMF, avec tous les avantages.
Le deuxième problème, c'est la lecture et la maintenance du code. C'est génial de lire le code source d'une classe, de se dire que ça fait ce qu'on veut, ou au contraire ça ne marche pas comme c'est écrit. Et là, paf ! Il faut savoir qu'il y a un produit, quelque part, qui va foutre sa sauce dans le code de ce produit, rendant obsolète ce qu'on a sous les yeux.
Sans parler des effets de bord. Difficile d'installer son produit qui compte sur le comportement d'une classe, en même temps qu'un produit qui va le modifier.
Bref, garde ces trucs de gorets pour Zope et passe à autre chose.
-- Hervé Cauwelier http://www.oursours.net/
Bonjour,
Lors d'une formation à CPS que j'ai pris à la volée, on m'a parlé de
"patches de classes".
Halala... éléver les techniques de goret au rang de méthode de
programmation...
Il y a deux problèmes. Le premier est que c'est une technique spécifique
à Zope car spécifique à ses problèmes, qu'on appelle un « monkey patch.
» Le fait est que les instances de classe sont persistantes et c'est la
merde pour les faire évoluer ou les remplacer par une instance d'une
autre classe, même si elle hérite de la classe d'origine.
Parce que, et j'insiste bien dessus, la meilleure méthode en
programmation objet et est reste d'hériter de la classe qu'on veut
surcharger et de charger les données pour créer un objet de cette
nouvelle classe, compatible avec l'ancien format. Mais c'est mort avec
Zope...
L'idée est alors d'aller attaquer directement la classe originale que
Zope charge au démarrage en changeant à la volée ses attributs et
classes, pour que les siens soient appelés à la place.
Puisqu'il s'agissait d'une formation CPS (hello Damien), il y a
longtemps qu'on aurait dû faire nos tools qui héritent de ceux de CMF,
au lieu de les patcher. Sauf que maintenant, il faudrait écrire des
scripts longs comme le bras pour migrer l'existant. Ils ont fini par
faire leur CPSUserFolder mais sans toucher aux instances existantes. Un
gros besoin serait un CPSCatalogTool qui intégrerait tous les monkey
patchs. De ce que j'ai vu de Plone, ils ont déjà leur version Plone des
outils CMF, avec tous les avantages.
Le deuxième problème, c'est la lecture et la maintenance du code. C'est
génial de lire le code source d'une classe, de se dire que ça fait ce
qu'on veut, ou au contraire ça ne marche pas comme c'est écrit. Et là,
paf ! Il faut savoir qu'il y a un produit, quelque part, qui va foutre
sa sauce dans le code de ce produit, rendant obsolète ce qu'on a sous
les yeux.
Sans parler des effets de bord. Difficile d'installer son produit qui
compte sur le comportement d'une classe, en même temps qu'un produit qui
va le modifier.
Bref, garde ces trucs de gorets pour Zope et passe à autre chose.
Lors d'une formation à CPS que j'ai pris à la volée, on m'a parlé de "patches de classes".
Halala... éléver les techniques de goret au rang de méthode de programmation...
Il y a deux problèmes. Le premier est que c'est une technique spécifique à Zope car spécifique à ses problèmes, qu'on appelle un « monkey patch. » Le fait est que les instances de classe sont persistantes et c'est la merde pour les faire évoluer ou les remplacer par une instance d'une autre classe, même si elle hérite de la classe d'origine.
Parce que, et j'insiste bien dessus, la meilleure méthode en programmation objet et est reste d'hériter de la classe qu'on veut surcharger et de charger les données pour créer un objet de cette nouvelle classe, compatible avec l'ancien format. Mais c'est mort avec Zope...
L'idée est alors d'aller attaquer directement la classe originale que Zope charge au démarrage en changeant à la volée ses attributs et classes, pour que les siens soient appelés à la place.
Puisqu'il s'agissait d'une formation CPS (hello Damien), il y a longtemps qu'on aurait dû faire nos tools qui héritent de ceux de CMF, au lieu de les patcher. Sauf que maintenant, il faudrait écrire des scripts longs comme le bras pour migrer l'existant. Ils ont fini par faire leur CPSUserFolder mais sans toucher aux instances existantes. Un gros besoin serait un CPSCatalogTool qui intégrerait tous les monkey patchs. De ce que j'ai vu de Plone, ils ont déjà leur version Plone des outils CMF, avec tous les avantages.
Le deuxième problème, c'est la lecture et la maintenance du code. C'est génial de lire le code source d'une classe, de se dire que ça fait ce qu'on veut, ou au contraire ça ne marche pas comme c'est écrit. Et là, paf ! Il faut savoir qu'il y a un produit, quelque part, qui va foutre sa sauce dans le code de ce produit, rendant obsolète ce qu'on a sous les yeux.
Sans parler des effets de bord. Difficile d'installer son produit qui compte sur le comportement d'une classe, en même temps qu'un produit qui va le modifier.
Bref, garde ces trucs de gorets pour Zope et passe à autre chose.
-- Hervé Cauwelier http://www.oursours.net/
R12y
On Mon, 07 Nov 2005 11:16:26 +0100, Hervé Cauwelier wrote:
Halala... éléver les techniques de goret au rang de méthode de programmation...
Ok, le mot clé qui me manquait était "monkey match". Le fait d'aller chercher avec "python patch" ne risquait pas d'aller loin.
Bon je suis d'accord pour dire que c'est une "mauvaise pratique", mais dans l'environement en question, dans lequel j'esaie d'avancer, c'est une pratque répandue et sans pour autant l'adopter, je dois au moins pouvoir le savoir ;-).
Bon je suis d'accord pour dire que c'est une "mauvaise pratique", mais
dans l'environement en question, dans lequel j'esaie d'avancer, c'est une
pratque répandue et sans pour autant l'adopter, je dois au moins pouvoir
le savoir ;-).
Bon je suis d'accord pour dire que c'est une "mauvaise pratique", mais dans l'environement en question, dans lequel j'esaie d'avancer, c'est une pratque répandue et sans pour autant l'adopter, je dois au moins pouvoir le savoir ;-).
