(snip)On 21 mai, 15:07, MCI, Shadok Gouroudoudou wrote:
pour les Mixins, je pensais par exemple à ceci :
http://sebulba.wikispaces.com/recipe+real+mixins
bouah, c'est trop horrible,
Ah bon ? Pourquoi donc ?faut tout arrêter à ce stade. La solution proposée ne présente aucun
intéret que de s'embarasser de problème qu'on a pas avec l'héritage
multiple.
Hmm... Il faudrait probablement réfléchir plus que je ne l'ai fait
pourle moment aux avantages et inconvénients comparés des deux solutions,
mais le fait est que l'héritage multiple n'a pas non plus que des
avantages. Ceux qui ont un peu hacké Zope2 en savent quelque chose...
Mais bon, pour être clair, quel est l'interet de la méthode ?
Recopier dans chaque classe les méthodes d'une autre ?
Ce n'est pas une recopie, c'est une injection.
C'est justement pour éviter cela qu'on a inventé l'héritage. Et puis
comment on gère les collisions de nom avec cette technique ?
C'est la notation ? Non, sérieux.
Franchement remplacer l'héritage pour ça c'est comme se tirer une
balle dans le pied.
Gérer correctement l'héritage multiple n'est pas non plus toujours une
partie de plaisir. Mais honnêtement, je réagissais surtout (et en me
faisant quelque peu l'avocat du diable, je l'avoue) au côté un peu
absolu de tes propos.
Personnellement, quand je vois une solution à
laquelle je n'avais pas pensé avant, j'aime bien prendre le temps de
l'étudier, ne serait-ce que pour voir ce qu'il y a à en apprendre. Dans
ce cas précis, et sur le fond, il faudrais que je me penche un peu plus
sur la question pour avoir un avis sur les avantages et inconvénients de
la solution.
L'héritage est fait pour ça, hériter du comportement d'une autre
classe. La seule autre relation connue, d'un point de vue POO, entre
deux objets c'est l'agrégation
Non. Il y a aussi - officiellement - la relation et la composition.
(snip)Si au moins l'exemple était écrit en évitant l'horrible utilisation
d'inspect, qui dénote souvent qu'on fait quelque chose de très
vilain,
Mon Dieu, je réalise soudainement que je fais régulièrement des trucs
très vilains trop horribles. C'est affreux, et mes programmes qui
tournent si bien ! Que dois-je faire, Docteur ?
Honnêtement: Python est un langage dynamique avec d'excellentes
capacités en matière d'introspection. Au nom de quel dogme devrait-on
s'abstenir d'en tirer partie ? Attention, je ne dis pas qu'il faille
systématiquement utiliser les possibilités les plus avancées, mais
de làà cataloguer de la sorte toute utilisation d'un module qui fait partie
de la bibliothèque standard, c'est peu être un poil expéditif.
J'utilisesouvent inspect, et occasionnellement le monkeypatching, et d'une
manière générale le résultat est nettement moins vilain que si je
ne lefaisais pas.
inspect c'est bien, super, c'est pour ces possibilité là que Pÿthon
(en tant que langage à typage dynamique)
Tu peux laisser de côté le 'à typage', AMHA - il n'y a pas que ça de
dynamique en Python.
est de loin supérieur à Java, disons. Le rôle d'inspect c'est de
permettre au programmeur de travailler sur les frame, de naviguer dans
la pile etc.
Pas uniquement. Dans un framework mvc sauce web, c'est une bonne façon
de passer au controleur les arguments de la requête - ce qui évite au
développeur du contrôleur d'avoir à le faire. En ce qui me concerne,
j'aime bien factoriser tout ce qui peut l'être.
Quand on s'en sert pour résoudre des problèmes de conception, j'ai un
doute, j'aurai tendance à penser que le problème est mal posé au
départ où la solution un peu trop tordu.
Penser que la conception puisse être totalement découplée de
l'implémentation est AMHA un mythe.
Concernant le monkey patching, je ne le condamne pas, au contraire,
c'est un outil que j'utilise très souvent avec beaucoup de plaisir, et
qui, a contrario de ce que l'on pourrait croire quand on vient de la
programmation "statique", est parfaitement sûr.
Son but ? Surcharger le comportement d'un objet existant et sur lequel
on a pas le contrôle. L'utiliser pour *définir* est donc a priori
inaproprié et très certainement tiré par les cheveux.
Mmm... Que ce soit une approche un peu latérale, j'en conviens. De là à
la rejeter d'office, il y a un pas que je m'empresse de ne pas franchir.
(snip)il ne faut pas chercher à retranscrire ce qu'on
trouve ailleurs tel quel (c'est aussi ce genre de choses qui me font
dire que Ruby n'est pas un langage encore très stable/mature dans sa
conception, et qu'il vaut mieux avoir un héritage multiple consistent
à la Python que d'avoir à faire des trucs dans le genre).
Il ne faut peut-être pas non plus juger les solutions d'un langage
d'après le concepts d'un autre langage ? Les modules mixin de Ruby
répondent à la grande majorité des cas d'utilisation de l'héritage
multiple tout en faisant l'économie des complexités de cette dernière.
C'est un choix de conception délibéré, et ce n'est certainement pas
AMHAle plus mauvais. S'il est évident que Ruby souffre encore de quelques
défauts de jeunesse, ils sont pour l'essentiel du côté de
l'implémentation.
Je veux pas cracher sur Ruby, je connais pas très bien. Si sa
conception manque de maturité, c'est plus une impression que j'ai à
chaque fois que je suis les discussions sur le sujet.
J'ai tendance à penser que c'est un peu fourre-tout, leur façon
d'ajouter des nouvelles fonctionnalités au language, à la différence
de ce qui se passe avec Python, qui a beaucoup évolué lui aussi avec
les dernières versions, mais toujurs dans le sens d'une plus grande
cohérence générale, d'une unification des différentes solutions
existantes. Alors qu'avec Ruby, quand j'ai suivi un tutoriel, à chaque
chapître j'avais l'impression de découvrir une nouvelle façon de faire
ce que j'avais appris à faire trois chapîtres plus tôt.
Il n'y a pas que dans les dernières versions que Python a beaucoup
évolué. Et une bonne part de ces évolutions n'étaient pas un luxe, loin
s'en faut. Ruby part avec un modèle objet bien plus cohérent et complet
que ne l'était celui de Python il y a quelques années, et des
possibilités dont je regrette qu'elles n'existent pas en Python.
Il y a
effectivement une nette différence philosophique entre Python et Ruby
concernant les différentes façons possible de dépiauter un chat, mais
dans la pratique Ruby tend à se fédérer autour de certains idiomes
dominants alors que Python s'est - historiquement - un peu éparpillé.
Je développe beaucoup sur Zope2, et c'est pas l'héritage multiple qui
est en question dans Zope2 (enfin je vois pas un seul problème concret
qui pourrait faire dire cela, des liens ?),
Non, l'expérience seulement.mais sa mauvaise utilisation. De toute façon la conception interne de
Zope ne respecte pas un des principe même du zen de Python "flat is
better, than nested". C'est la multiplication des classes et leur
imbrication qui est problématique et l'utilisation de l'héritage
systématique alors que d'autres techniques existent et seraient plus
apropriées.
<aol />
Du reste, je suis pas fan des solutions proposées dans la conception
de Zope3 : interfaces à la Java,
Là je t'arrête. Le système d'interfaces de Zope3 est sans grand rapport
avec celui de Java. Il ne s'agit pas en l'occurrence de pallier à
l'absence d'héritage multiple dans un langage dans lequel le typage
conditionne le polymorphisme, mais surtout de permettre d'adapter
dynamiquement diverses interfaces les unes aux autres. Même si le
résultat final est bien trop usineàgazesque pour mon goût, il y a AMHA
quelque chose de très intéressant qui se dessine de ce côté là - voire
aussi à ce propos les modules dispatch et protocol de Peak, et certaines
réflexions du BDFL sur les mérites comparés des deux approches et la
possibilité de faire se rejoindre (il faudrait que je retrouve l'url de
cette discussion d'ailleurs)Zcml, ..., tout ça ça fait très "mode" J2EE et cela rapproche
fatalement Zope de la lourdeur de J2EE.
<aol /> encore.
Mes deux centimes...
Les miens aussi.
Et je relance de trois !-)
(snip)
On 21 mai, 15:07, MCI, Shadok Gouroudoudou <pas...@spam.svp> wrote:
pour les Mixins, je pensais par exemple à ceci :
http://sebulba.wikispaces.com/recipe+real+mixins
bouah, c'est trop horrible,
Ah bon ? Pourquoi donc ?
faut tout arrêter à ce stade. La solution proposée ne présente aucun
intéret que de s'embarasser de problème qu'on a pas avec l'héritage
multiple.
Hmm... Il faudrait probablement réfléchir plus que je ne l'ai fait
pour
le moment aux avantages et inconvénients comparés des deux solutions,
mais le fait est que l'héritage multiple n'a pas non plus que des
avantages. Ceux qui ont un peu hacké Zope2 en savent quelque chose...
Mais bon, pour être clair, quel est l'interet de la méthode ?
Recopier dans chaque classe les méthodes d'une autre ?
Ce n'est pas une recopie, c'est une injection.
C'est justement pour éviter cela qu'on a inventé l'héritage. Et puis
comment on gère les collisions de nom avec cette technique ?
C'est la notation ? Non, sérieux.
Franchement remplacer l'héritage pour ça c'est comme se tirer une
balle dans le pied.
Gérer correctement l'héritage multiple n'est pas non plus toujours une
partie de plaisir. Mais honnêtement, je réagissais surtout (et en me
faisant quelque peu l'avocat du diable, je l'avoue) au côté un peu
absolu de tes propos.
Personnellement, quand je vois une solution à
laquelle je n'avais pas pensé avant, j'aime bien prendre le temps de
l'étudier, ne serait-ce que pour voir ce qu'il y a à en apprendre. Dans
ce cas précis, et sur le fond, il faudrais que je me penche un peu plus
sur la question pour avoir un avis sur les avantages et inconvénients de
la solution.
L'héritage est fait pour ça, hériter du comportement d'une autre
classe. La seule autre relation connue, d'un point de vue POO, entre
deux objets c'est l'agrégation
Non. Il y a aussi - officiellement - la relation et la composition.
(snip)
Si au moins l'exemple était écrit en évitant l'horrible utilisation
d'inspect, qui dénote souvent qu'on fait quelque chose de très
vilain,
Mon Dieu, je réalise soudainement que je fais régulièrement des trucs
très vilains trop horribles. C'est affreux, et mes programmes qui
tournent si bien ! Que dois-je faire, Docteur ?
Honnêtement: Python est un langage dynamique avec d'excellentes
capacités en matière d'introspection. Au nom de quel dogme devrait-on
s'abstenir d'en tirer partie ? Attention, je ne dis pas qu'il faille
systématiquement utiliser les possibilités les plus avancées, mais
de là
à cataloguer de la sorte toute utilisation d'un module qui fait partie
de la bibliothèque standard, c'est peu être un poil expéditif.
J'utilise
souvent inspect, et occasionnellement le monkeypatching, et d'une
manière générale le résultat est nettement moins vilain que si je
ne le
faisais pas.
inspect c'est bien, super, c'est pour ces possibilité là que Pÿthon
(en tant que langage à typage dynamique)
Tu peux laisser de côté le 'à typage', AMHA - il n'y a pas que ça de
dynamique en Python.
est de loin supérieur à Java, disons. Le rôle d'inspect c'est de
permettre au programmeur de travailler sur les frame, de naviguer dans
la pile etc.
Pas uniquement. Dans un framework mvc sauce web, c'est une bonne façon
de passer au controleur les arguments de la requête - ce qui évite au
développeur du contrôleur d'avoir à le faire. En ce qui me concerne,
j'aime bien factoriser tout ce qui peut l'être.
Quand on s'en sert pour résoudre des problèmes de conception, j'ai un
doute, j'aurai tendance à penser que le problème est mal posé au
départ où la solution un peu trop tordu.
Penser que la conception puisse être totalement découplée de
l'implémentation est AMHA un mythe.
Concernant le monkey patching, je ne le condamne pas, au contraire,
c'est un outil que j'utilise très souvent avec beaucoup de plaisir, et
qui, a contrario de ce que l'on pourrait croire quand on vient de la
programmation "statique", est parfaitement sûr.
Son but ? Surcharger le comportement d'un objet existant et sur lequel
on a pas le contrôle. L'utiliser pour *définir* est donc a priori
inaproprié et très certainement tiré par les cheveux.
Mmm... Que ce soit une approche un peu latérale, j'en conviens. De là à
la rejeter d'office, il y a un pas que je m'empresse de ne pas franchir.
(snip)
il ne faut pas chercher à retranscrire ce qu'on
trouve ailleurs tel quel (c'est aussi ce genre de choses qui me font
dire que Ruby n'est pas un langage encore très stable/mature dans sa
conception, et qu'il vaut mieux avoir un héritage multiple consistent
à la Python que d'avoir à faire des trucs dans le genre).
Il ne faut peut-être pas non plus juger les solutions d'un langage
d'après le concepts d'un autre langage ? Les modules mixin de Ruby
répondent à la grande majorité des cas d'utilisation de l'héritage
multiple tout en faisant l'économie des complexités de cette dernière.
C'est un choix de conception délibéré, et ce n'est certainement pas
AMHA
le plus mauvais. S'il est évident que Ruby souffre encore de quelques
défauts de jeunesse, ils sont pour l'essentiel du côté de
l'implémentation.
Je veux pas cracher sur Ruby, je connais pas très bien. Si sa
conception manque de maturité, c'est plus une impression que j'ai à
chaque fois que je suis les discussions sur le sujet.
J'ai tendance à penser que c'est un peu fourre-tout, leur façon
d'ajouter des nouvelles fonctionnalités au language, à la différence
de ce qui se passe avec Python, qui a beaucoup évolué lui aussi avec
les dernières versions, mais toujurs dans le sens d'une plus grande
cohérence générale, d'une unification des différentes solutions
existantes. Alors qu'avec Ruby, quand j'ai suivi un tutoriel, à chaque
chapître j'avais l'impression de découvrir une nouvelle façon de faire
ce que j'avais appris à faire trois chapîtres plus tôt.
Il n'y a pas que dans les dernières versions que Python a beaucoup
évolué. Et une bonne part de ces évolutions n'étaient pas un luxe, loin
s'en faut. Ruby part avec un modèle objet bien plus cohérent et complet
que ne l'était celui de Python il y a quelques années, et des
possibilités dont je regrette qu'elles n'existent pas en Python.
Il y a
effectivement une nette différence philosophique entre Python et Ruby
concernant les différentes façons possible de dépiauter un chat, mais
dans la pratique Ruby tend à se fédérer autour de certains idiomes
dominants alors que Python s'est - historiquement - un peu éparpillé.
Je développe beaucoup sur Zope2, et c'est pas l'héritage multiple qui
est en question dans Zope2 (enfin je vois pas un seul problème concret
qui pourrait faire dire cela, des liens ?),
Non, l'expérience seulement.
mais sa mauvaise utilisation. De toute façon la conception interne de
Zope ne respecte pas un des principe même du zen de Python "flat is
better, than nested". C'est la multiplication des classes et leur
imbrication qui est problématique et l'utilisation de l'héritage
systématique alors que d'autres techniques existent et seraient plus
apropriées.
<aol />
Du reste, je suis pas fan des solutions proposées dans la conception
de Zope3 : interfaces à la Java,
Là je t'arrête. Le système d'interfaces de Zope3 est sans grand rapport
avec celui de Java. Il ne s'agit pas en l'occurrence de pallier à
l'absence d'héritage multiple dans un langage dans lequel le typage
conditionne le polymorphisme, mais surtout de permettre d'adapter
dynamiquement diverses interfaces les unes aux autres. Même si le
résultat final est bien trop usineàgazesque pour mon goût, il y a AMHA
quelque chose de très intéressant qui se dessine de ce côté là - voire
aussi à ce propos les modules dispatch et protocol de Peak, et certaines
réflexions du BDFL sur les mérites comparés des deux approches et la
possibilité de faire se rejoindre (il faudrait que je retrouve l'url de
cette discussion d'ailleurs)
Zcml, ..., tout ça ça fait très "mode" J2EE et cela rapproche
fatalement Zope de la lourdeur de J2EE.
<aol /> encore.
Mes deux centimes...
Les miens aussi.
Et je relance de trois !-)
(snip)On 21 mai, 15:07, MCI, Shadok Gouroudoudou wrote:
pour les Mixins, je pensais par exemple à ceci :
http://sebulba.wikispaces.com/recipe+real+mixins
bouah, c'est trop horrible,
Ah bon ? Pourquoi donc ?faut tout arrêter à ce stade. La solution proposée ne présente aucun
intéret que de s'embarasser de problème qu'on a pas avec l'héritage
multiple.
Hmm... Il faudrait probablement réfléchir plus que je ne l'ai fait
pourle moment aux avantages et inconvénients comparés des deux solutions,
mais le fait est que l'héritage multiple n'a pas non plus que des
avantages. Ceux qui ont un peu hacké Zope2 en savent quelque chose...
Mais bon, pour être clair, quel est l'interet de la méthode ?
Recopier dans chaque classe les méthodes d'une autre ?
Ce n'est pas une recopie, c'est une injection.
C'est justement pour éviter cela qu'on a inventé l'héritage. Et puis
comment on gère les collisions de nom avec cette technique ?
C'est la notation ? Non, sérieux.
Franchement remplacer l'héritage pour ça c'est comme se tirer une
balle dans le pied.
Gérer correctement l'héritage multiple n'est pas non plus toujours une
partie de plaisir. Mais honnêtement, je réagissais surtout (et en me
faisant quelque peu l'avocat du diable, je l'avoue) au côté un peu
absolu de tes propos.
Personnellement, quand je vois une solution à
laquelle je n'avais pas pensé avant, j'aime bien prendre le temps de
l'étudier, ne serait-ce que pour voir ce qu'il y a à en apprendre. Dans
ce cas précis, et sur le fond, il faudrais que je me penche un peu plus
sur la question pour avoir un avis sur les avantages et inconvénients de
la solution.
L'héritage est fait pour ça, hériter du comportement d'une autre
classe. La seule autre relation connue, d'un point de vue POO, entre
deux objets c'est l'agrégation
Non. Il y a aussi - officiellement - la relation et la composition.
(snip)Si au moins l'exemple était écrit en évitant l'horrible utilisation
d'inspect, qui dénote souvent qu'on fait quelque chose de très
vilain,
Mon Dieu, je réalise soudainement que je fais régulièrement des trucs
très vilains trop horribles. C'est affreux, et mes programmes qui
tournent si bien ! Que dois-je faire, Docteur ?
Honnêtement: Python est un langage dynamique avec d'excellentes
capacités en matière d'introspection. Au nom de quel dogme devrait-on
s'abstenir d'en tirer partie ? Attention, je ne dis pas qu'il faille
systématiquement utiliser les possibilités les plus avancées, mais
de làà cataloguer de la sorte toute utilisation d'un module qui fait partie
de la bibliothèque standard, c'est peu être un poil expéditif.
J'utilisesouvent inspect, et occasionnellement le monkeypatching, et d'une
manière générale le résultat est nettement moins vilain que si je
ne lefaisais pas.
inspect c'est bien, super, c'est pour ces possibilité là que Pÿthon
(en tant que langage à typage dynamique)
Tu peux laisser de côté le 'à typage', AMHA - il n'y a pas que ça de
dynamique en Python.
est de loin supérieur à Java, disons. Le rôle d'inspect c'est de
permettre au programmeur de travailler sur les frame, de naviguer dans
la pile etc.
Pas uniquement. Dans un framework mvc sauce web, c'est une bonne façon
de passer au controleur les arguments de la requête - ce qui évite au
développeur du contrôleur d'avoir à le faire. En ce qui me concerne,
j'aime bien factoriser tout ce qui peut l'être.
Quand on s'en sert pour résoudre des problèmes de conception, j'ai un
doute, j'aurai tendance à penser que le problème est mal posé au
départ où la solution un peu trop tordu.
Penser que la conception puisse être totalement découplée de
l'implémentation est AMHA un mythe.
Concernant le monkey patching, je ne le condamne pas, au contraire,
c'est un outil que j'utilise très souvent avec beaucoup de plaisir, et
qui, a contrario de ce que l'on pourrait croire quand on vient de la
programmation "statique", est parfaitement sûr.
Son but ? Surcharger le comportement d'un objet existant et sur lequel
on a pas le contrôle. L'utiliser pour *définir* est donc a priori
inaproprié et très certainement tiré par les cheveux.
Mmm... Que ce soit une approche un peu latérale, j'en conviens. De là à
la rejeter d'office, il y a un pas que je m'empresse de ne pas franchir.
(snip)il ne faut pas chercher à retranscrire ce qu'on
trouve ailleurs tel quel (c'est aussi ce genre de choses qui me font
dire que Ruby n'est pas un langage encore très stable/mature dans sa
conception, et qu'il vaut mieux avoir un héritage multiple consistent
à la Python que d'avoir à faire des trucs dans le genre).
Il ne faut peut-être pas non plus juger les solutions d'un langage
d'après le concepts d'un autre langage ? Les modules mixin de Ruby
répondent à la grande majorité des cas d'utilisation de l'héritage
multiple tout en faisant l'économie des complexités de cette dernière.
C'est un choix de conception délibéré, et ce n'est certainement pas
AMHAle plus mauvais. S'il est évident que Ruby souffre encore de quelques
défauts de jeunesse, ils sont pour l'essentiel du côté de
l'implémentation.
Je veux pas cracher sur Ruby, je connais pas très bien. Si sa
conception manque de maturité, c'est plus une impression que j'ai à
chaque fois que je suis les discussions sur le sujet.
J'ai tendance à penser que c'est un peu fourre-tout, leur façon
d'ajouter des nouvelles fonctionnalités au language, à la différence
de ce qui se passe avec Python, qui a beaucoup évolué lui aussi avec
les dernières versions, mais toujurs dans le sens d'une plus grande
cohérence générale, d'une unification des différentes solutions
existantes. Alors qu'avec Ruby, quand j'ai suivi un tutoriel, à chaque
chapître j'avais l'impression de découvrir une nouvelle façon de faire
ce que j'avais appris à faire trois chapîtres plus tôt.
Il n'y a pas que dans les dernières versions que Python a beaucoup
évolué. Et une bonne part de ces évolutions n'étaient pas un luxe, loin
s'en faut. Ruby part avec un modèle objet bien plus cohérent et complet
que ne l'était celui de Python il y a quelques années, et des
possibilités dont je regrette qu'elles n'existent pas en Python.
Il y a
effectivement une nette différence philosophique entre Python et Ruby
concernant les différentes façons possible de dépiauter un chat, mais
dans la pratique Ruby tend à se fédérer autour de certains idiomes
dominants alors que Python s'est - historiquement - un peu éparpillé.
Je développe beaucoup sur Zope2, et c'est pas l'héritage multiple qui
est en question dans Zope2 (enfin je vois pas un seul problème concret
qui pourrait faire dire cela, des liens ?),
Non, l'expérience seulement.mais sa mauvaise utilisation. De toute façon la conception interne de
Zope ne respecte pas un des principe même du zen de Python "flat is
better, than nested". C'est la multiplication des classes et leur
imbrication qui est problématique et l'utilisation de l'héritage
systématique alors que d'autres techniques existent et seraient plus
apropriées.
<aol />
Du reste, je suis pas fan des solutions proposées dans la conception
de Zope3 : interfaces à la Java,
Là je t'arrête. Le système d'interfaces de Zope3 est sans grand rapport
avec celui de Java. Il ne s'agit pas en l'occurrence de pallier à
l'absence d'héritage multiple dans un langage dans lequel le typage
conditionne le polymorphisme, mais surtout de permettre d'adapter
dynamiquement diverses interfaces les unes aux autres. Même si le
résultat final est bien trop usineàgazesque pour mon goût, il y a AMHA
quelque chose de très intéressant qui se dessine de ce côté là - voire
aussi à ce propos les modules dispatch et protocol de Peak, et certaines
réflexions du BDFL sur les mérites comparés des deux approches et la
possibilité de faire se rejoindre (il faudrait que je retrouve l'url de
cette discussion d'ailleurs)Zcml, ..., tout ça ça fait très "mode" J2EE et cela rapproche
fatalement Zope de la lourdeur de J2EE.
<aol /> encore.
Mes deux centimes...
Les miens aussi.
Et je relance de trois !-)
- de plugins pour une application quelconque, sans utiliser de
solution tierces (egg, autres);
[de mes bookmarks]
Tu peux t'inspirer de http://termie.pbwiki.com/SprinklesPy
Et en PJ ce que j'utilise dans PyExp (il faut en virer le logger de
pyexp et le remplacer par ce que tu utilises).
------------------------------------------------------------------------
- de plugins pour une application quelconque, sans utiliser de
solution tierces (egg, autres);
[de mes bookmarks]
Tu peux t'inspirer de http://termie.pbwiki.com/SprinklesPy
Et en PJ ce que j'utilise dans PyExp (il faut en virer le logger de
pyexp et le remplacer par ce que tu utilises).
------------------------------------------------------------------------
- de plugins pour une application quelconque, sans utiliser de
solution tierces (egg, autres);
[de mes bookmarks]
Tu peux t'inspirer de http://termie.pbwiki.com/SprinklesPy
Et en PJ ce que j'utilise dans PyExp (il faut en virer le logger de
pyexp et le remplacer par ce que tu utilises).
------------------------------------------------------------------------
En ce qui concerne SprinklesPy, je l'avais déjà bookmarké il y a
longtemps, mais je ne trouve pas de liens concernant les sources, elles
semblent avoir disparues.
En ce qui concerne SprinklesPy, je l'avais déjà bookmarké il y a
longtemps, mais je ne trouve pas de liens concernant les sources, elles
semblent avoir disparues.
En ce qui concerne SprinklesPy, je l'avais déjà bookmarké il y a
longtemps, mais je ne trouve pas de liens concernant les sources, elles
semblent avoir disparues.
En ce qui concerne SprinklesPy, je l'avais déjà bookmarké il y a
longtemps, mais je ne trouve pas de liens concernant les sources,
elles semblent avoir disparues.
Tu peux contacter l'auteur, indiqué en bas de la page...
http://termie.pbwiki.com/AndySmith
Ok, je fais ça de suite, merci.
En ce qui concerne SprinklesPy, je l'avais déjà bookmarké il y a
longtemps, mais je ne trouve pas de liens concernant les sources,
elles semblent avoir disparues.
Tu peux contacter l'auteur, indiqué en bas de la page...
http://termie.pbwiki.com/AndySmith
Ok, je fais ça de suite, merci.
En ce qui concerne SprinklesPy, je l'avais déjà bookmarké il y a
longtemps, mais je ne trouve pas de liens concernant les sources,
elles semblent avoir disparues.
Tu peux contacter l'auteur, indiqué en bas de la page...
http://termie.pbwiki.com/AndySmith
Ok, je fais ça de suite, merci.
<aol />
hmmm, c'est dur de pas un ancien de usenet des fois, Google m'envoie sur
un portail dont je ne ferais pas la publicité :(
<aol />
hmmm, c'est dur de pas un ancien de usenet des fois, Google m'envoie sur
un portail dont je ne ferais pas la publicité :(
<aol />
hmmm, c'est dur de pas un ancien de usenet des fois, Google m'envoie sur
un portail dont je ne ferais pas la publicité :(
<aol />
hmmm, c'est dur de pas un ancien de usenet des fois, Google m'envoie
sur un portail dont je ne ferais pas la publicité :(
Bon alors, sans rire, ça veut dire quoi "<aol />" ?
<aol />
hmmm, c'est dur de pas un ancien de usenet des fois, Google m'envoie
sur un portail dont je ne ferais pas la publicité :(
Bon alors, sans rire, ça veut dire quoi "<aol />" ?
<aol />
hmmm, c'est dur de pas un ancien de usenet des fois, Google m'envoie
sur un portail dont je ne ferais pas la publicité :(
Bon alors, sans rire, ça veut dire quoi "<aol />" ?
Myxine : un peu de biologie, pour changer...
La myxine est un poisson, une sorte de lamproie (il y a beaucoup de
lamproies dans l'Ardèche), qui n'a ni mâchoires, ni vertèbres.
On ne savait pas trop où classer cette famille. Mais, une étude
japonaise récente, sur l'embryogenèse (évolution des oeufs) à montré que
l'évolution primale de la molle épinière, et du système nerveux, est
similaire à celle des vertébrés. De plus, certains gènes propres aux
vertébrés existent dans son génome, même s'ils ne sont pas exprimés.
La question, maintenant, est de savoir s'il s'agit d'un "pré-vertébré"
(comme un ancêtre), ou d'un vertébré dégénéré, qui aurait perdu
certaines caractéristiques.
Petits détails : Ce poisson rentre à l'intérieur des poissons morts ou
malades, pour les digérer, de l'intérieur.
Et, lorsqu'il se sent menacé, son corps expulse une sorte de poudre
déshydratée, qui se gonfle immédiatement au contact de l'eau, de 10 à 20
fois son volume, en une espèce de gelée qui étouffe littéralement son
prédateur.
Myxine : un peu de biologie, pour changer...
La myxine est un poisson, une sorte de lamproie (il y a beaucoup de
lamproies dans l'Ardèche), qui n'a ni mâchoires, ni vertèbres.
On ne savait pas trop où classer cette famille. Mais, une étude
japonaise récente, sur l'embryogenèse (évolution des oeufs) à montré que
l'évolution primale de la molle épinière, et du système nerveux, est
similaire à celle des vertébrés. De plus, certains gènes propres aux
vertébrés existent dans son génome, même s'ils ne sont pas exprimés.
La question, maintenant, est de savoir s'il s'agit d'un "pré-vertébré"
(comme un ancêtre), ou d'un vertébré dégénéré, qui aurait perdu
certaines caractéristiques.
Petits détails : Ce poisson rentre à l'intérieur des poissons morts ou
malades, pour les digérer, de l'intérieur.
Et, lorsqu'il se sent menacé, son corps expulse une sorte de poudre
déshydratée, qui se gonfle immédiatement au contact de l'eau, de 10 à 20
fois son volume, en une espèce de gelée qui étouffe littéralement son
prédateur.
Myxine : un peu de biologie, pour changer...
La myxine est un poisson, une sorte de lamproie (il y a beaucoup de
lamproies dans l'Ardèche), qui n'a ni mâchoires, ni vertèbres.
On ne savait pas trop où classer cette famille. Mais, une étude
japonaise récente, sur l'embryogenèse (évolution des oeufs) à montré que
l'évolution primale de la molle épinière, et du système nerveux, est
similaire à celle des vertébrés. De plus, certains gènes propres aux
vertébrés existent dans son génome, même s'ils ne sont pas exprimés.
La question, maintenant, est de savoir s'il s'agit d'un "pré-vertébré"
(comme un ancêtre), ou d'un vertébré dégénéré, qui aurait perdu
certaines caractéristiques.
Petits détails : Ce poisson rentre à l'intérieur des poissons morts ou
malades, pour les digérer, de l'intérieur.
Et, lorsqu'il se sent menacé, son corps expulse une sorte de poudre
déshydratée, qui se gonfle immédiatement au contact de l'eau, de 10 à 20
fois son volume, en une espèce de gelée qui étouffe littéralement son
prédateur.
En tout cas, on ne s'écarte pas du sujet:
En tout cas, on ne s'écarte pas du sujet:
En tout cas, on ne s'écarte pas du sujet: