Et il est dommage que ce "toolkit" soit aussi ancien.
Perso, plus ça va, moins la programmation fonctionnelle me séduit.
Ah ? Tu n'utilises donc ni les décorateurs, ni les expressions de listes, ni même les fonctions de rappel ?-)
R12y
On Sat, 15 Oct 2005 18:52:16 +0200, Do Re Mi chel La Si Do wrote:
Ceci dit, ça pourrait intéresser R12y
Effectivement. Mais force est de constater que je sais pas faire la différence entre ce qui est "fonctionnel" et ce qui ne l'est pas.
En effet, je ne comprends pas pourquoi le code proposé par Salvatore, exécuté avec un python 2.4 sans le toolkit, se vautre ici: (faites pas attention aux In[x], c'est le prompt d'ipython)
...: In [3]: emp1 = Employe('Paul',123,False) In [4]: emp2 = Employe('Aline',1234,True) In [5]: emp3 = Employe('Henry',567,True) In [6]: emps = [emp1,emp2,emp3] In [7]: f = augSalCadre(emps,200) In [8]: map(f,emps) Out[8]: [<__main__.Employe instance at 0xb7b44eec>, <__main__.Employe instance at 0xb7b48fec>, <__main__.Employe instance at 0xb7b48bec>]
En quoi est ce que c'est si "fonctionnel" que cela, ce bout de code?
Qu'on ait mit une fonction en premier argument de map()? mais map est fait justement pour appliquer un traitement (donc une fonction) à chaque éléments du 2nd argument! Je ne trouve pas l'emboitement de fonctions typique de ce type de programmation... mais je dois mal regarder, et au vu de l'heure tardive ça pourrait se comprendre... Mais ça me trotte dans la tête quand même...
On Sat, 15 Oct 2005 18:52:16 +0200, Do Re Mi chel La Si Do wrote:
Ceci dit, ça pourrait intéresser R12y
Effectivement. Mais force est de constater que je sais pas faire la
différence entre ce qui est "fonctionnel" et ce qui ne l'est pas.
En effet, je ne comprends pas pourquoi le code proposé par Salvatore,
exécuté avec un python 2.4 sans le toolkit, se vautre ici: (faites pas
attention aux In[x], c'est le prompt d'ipython)
...:
In [3]: emp1 = Employe('Paul',123,False)
In [4]: emp2 = Employe('Aline',1234,True)
In [5]: emp3 = Employe('Henry',567,True)
In [6]: emps = [emp1,emp2,emp3]
In [7]: f = augSalCadre(emps,200)
In [8]: map(f,emps)
Out[8]:
[<__main__.Employe instance at 0xb7b44eec>,
<__main__.Employe instance at 0xb7b48fec>,
<__main__.Employe instance at 0xb7b48bec>]
En quoi est ce que c'est si "fonctionnel" que cela, ce bout de code?
Qu'on ait mit une fonction en premier argument de map()? mais map est fait
justement pour appliquer un traitement (donc une fonction) à chaque
éléments du 2nd argument!
Je ne trouve pas l'emboitement de fonctions typique de ce type de
programmation... mais je dois mal regarder, et au vu de l'heure tardive ça
pourrait se comprendre... Mais ça me trotte dans la tête quand même...
On Sat, 15 Oct 2005 18:52:16 +0200, Do Re Mi chel La Si Do wrote:
Ceci dit, ça pourrait intéresser R12y
Effectivement. Mais force est de constater que je sais pas faire la différence entre ce qui est "fonctionnel" et ce qui ne l'est pas.
En effet, je ne comprends pas pourquoi le code proposé par Salvatore, exécuté avec un python 2.4 sans le toolkit, se vautre ici: (faites pas attention aux In[x], c'est le prompt d'ipython)
...: In [3]: emp1 = Employe('Paul',123,False) In [4]: emp2 = Employe('Aline',1234,True) In [5]: emp3 = Employe('Henry',567,True) In [6]: emps = [emp1,emp2,emp3] In [7]: f = augSalCadre(emps,200) In [8]: map(f,emps) Out[8]: [<__main__.Employe instance at 0xb7b44eec>, <__main__.Employe instance at 0xb7b48fec>, <__main__.Employe instance at 0xb7b48bec>]
En quoi est ce que c'est si "fonctionnel" que cela, ce bout de code?
Qu'on ait mit une fonction en premier argument de map()? mais map est fait justement pour appliquer un traitement (donc une fonction) à chaque éléments du 2nd argument! Je ne trouve pas l'emboitement de fonctions typique de ce type de programmation... mais je dois mal regarder, et au vu de l'heure tardive ça pourrait se comprendre... Mais ça me trotte dans la tête quand même...
On Sat, 15 Oct 2005 18:52:16 +0200, Do Re Mi chel La Si Do wrote:
Ceci dit, ça pourrait intéresser R12y
Effectivement. Mais force est de constater que je sais pas faire la différence entre ce qui est "fonctionnel" et ce qui ne l'est pas.
En effet, je ne comprends pas pourquoi le code proposé par Salvatore, exécuté avec un python 2.4 sans le toolkit, se vautre ici: (faites pas attention aux In[x], c'est le prompt d'ipython)
...: In [3]: emp1 = Employe('Paul',123,False) In [4]: emp2 = Employe('Aline',1234,True) In [5]: emp3 = Employe('Henry',567,True) In [6]: emps = [emp1,emp2,emp3] In [7]: f = augSalCadre(emps,200) In [8]: map(f,emps) Out[8]: [<__main__.Employe instance at 0xb7b44eec>, <__main__.Employe instance at 0xb7b48fec>, <__main__.Employe instance at 0xb7b48bec>]
En quoi est ce que c'est si "fonctionnel" que cela, ce bout de code?
Qu'on ait mit une fonction en premier argument de map()? mais map est fait justement pour appliquer un traitement (donc une fonction) à chaque éléments du 2nd argument! Je ne trouve pas l'emboitement de fonctions typique de ce type de programmation... mais je dois mal regarder, et au vu de l'heure tardive ça pourrait se comprendre... Mais ça me trotte dans la tête quand même...
Je dirais que la plus grande difference entre la programation fonctionnelle et la programation imperative viens de la mutabilité des variable. En effet, une grande constante en programation fonctionnelle est qu'une fois définies, on ne change jamais la valeur d'une variable. Les opérations comme la boucle for du Python sont ici considérées comme ne changeant pas la valeur de la variable d'iteration.
On Sat, 15 Oct 2005 18:52:16 +0200, Do Re Mi chel La Si Do wrote:
Ceci dit, ça pourrait intéresser R12y
Effectivement. Mais force est de constater que je sais pas faire la
différence entre ce qui est "fonctionnel" et ce qui ne l'est pas.
En effet, je ne comprends pas pourquoi le code proposé par Salvatore,
exécuté avec un python 2.4 sans le toolkit, se vautre ici: (faites pas
attention aux In[x], c'est le prompt d'ipython)
...:
In [3]: emp1 = Employe('Paul',123,False)
In [4]: emp2 = Employe('Aline',1234,True)
In [5]: emp3 = Employe('Henry',567,True)
In [6]: emps = [emp1,emp2,emp3]
In [7]: f = augSalCadre(emps,200)
In [8]: map(f,emps)
Out[8]:
[<__main__.Employe instance at 0xb7b44eec>,
<__main__.Employe instance at 0xb7b48fec>,
<__main__.Employe instance at 0xb7b48bec>]
En quoi est ce que c'est si "fonctionnel" que cela, ce bout de code?
Qu'on ait mit une fonction en premier argument de map()? mais map est fait
justement pour appliquer un traitement (donc une fonction) à chaque
éléments du 2nd argument!
Je ne trouve pas l'emboitement de fonctions typique de ce type de
programmation... mais je dois mal regarder, et au vu de l'heure tardive ça
pourrait se comprendre... Mais ça me trotte dans la tête quand même...
Je dirais que la plus grande difference entre la programation
fonctionnelle et la programation imperative viens de la mutabilité des
variable. En effet, une grande constante en programation fonctionnelle
est qu'une fois définies, on ne change jamais la valeur d'une variable.
Les opérations comme la boucle for du Python sont ici considérées comme
ne changeant pas la valeur de la variable d'iteration.
On Sat, 15 Oct 2005 18:52:16 +0200, Do Re Mi chel La Si Do wrote:
Ceci dit, ça pourrait intéresser R12y
Effectivement. Mais force est de constater que je sais pas faire la différence entre ce qui est "fonctionnel" et ce qui ne l'est pas.
En effet, je ne comprends pas pourquoi le code proposé par Salvatore, exécuté avec un python 2.4 sans le toolkit, se vautre ici: (faites pas attention aux In[x], c'est le prompt d'ipython)
...: In [3]: emp1 = Employe('Paul',123,False) In [4]: emp2 = Employe('Aline',1234,True) In [5]: emp3 = Employe('Henry',567,True) In [6]: emps = [emp1,emp2,emp3] In [7]: f = augSalCadre(emps,200) In [8]: map(f,emps) Out[8]: [<__main__.Employe instance at 0xb7b44eec>, <__main__.Employe instance at 0xb7b48fec>, <__main__.Employe instance at 0xb7b48bec>]
En quoi est ce que c'est si "fonctionnel" que cela, ce bout de code?
Qu'on ait mit une fonction en premier argument de map()? mais map est fait justement pour appliquer un traitement (donc une fonction) à chaque éléments du 2nd argument! Je ne trouve pas l'emboitement de fonctions typique de ce type de programmation... mais je dois mal regarder, et au vu de l'heure tardive ça pourrait se comprendre... Mais ça me trotte dans la tête quand même...
Je dirais que la plus grande difference entre la programation fonctionnelle et la programation imperative viens de la mutabilité des variable. En effet, une grande constante en programation fonctionnelle est qu'une fois définies, on ne change jamais la valeur d'une variable. Les opérations comme la boucle for du Python sont ici considérées comme ne changeant pas la valeur de la variable d'iteration.
Do Re Mi chel La Si Do
Bonsoir !
Tu n'utilises donc ni les décorateurs, ni les expressions de listes, ni même les fonctions de rappel
1) Non, je n'utilise pas les décorateurs. Je préfère décorer moi-même mon sapin de noël. 2) je jubile, à l'idée de lister tes expressions, lorsque tu liras ce message. 3) je ne me rappelle plus quelle fonction j'occupe.
Sinon : - les décorateurs, c'est marrant, mais, en réalité, ça ne m'apporte pas grand chose. - les listes en intentions, en pratique, je fais d'abord ma routine, classiquement, puis, ensuite, je reécrit en les utilisant. Donc, ça ne m'est pas indispensable. - les callback, ça, oui, je n'arrête pas de m'en servir. Mais ce n'est pas une exclusivité de la P.F.
@+
MCI
Bonsoir !
Tu n'utilises donc ni les décorateurs, ni les expressions de listes, ni
même les fonctions de rappel
1) Non, je n'utilise pas les décorateurs. Je préfère décorer moi-même mon
sapin de noël.
2) je jubile, à l'idée de lister tes expressions, lorsque tu liras ce
message.
3) je ne me rappelle plus quelle fonction j'occupe.
Sinon :
- les décorateurs, c'est marrant, mais, en réalité, ça ne m'apporte pas
grand chose.
- les listes en intentions, en pratique, je fais d'abord ma routine,
classiquement, puis, ensuite, je reécrit en les utilisant. Donc, ça ne m'est
pas indispensable.
- les callback, ça, oui, je n'arrête pas de m'en servir. Mais ce n'est pas
une exclusivité de la P.F.
Tu n'utilises donc ni les décorateurs, ni les expressions de listes, ni même les fonctions de rappel
1) Non, je n'utilise pas les décorateurs. Je préfère décorer moi-même mon sapin de noël. 2) je jubile, à l'idée de lister tes expressions, lorsque tu liras ce message. 3) je ne me rappelle plus quelle fonction j'occupe.
Sinon : - les décorateurs, c'est marrant, mais, en réalité, ça ne m'apporte pas grand chose. - les listes en intentions, en pratique, je fais d'abord ma routine, classiquement, puis, ensuite, je reécrit en les utilisant. Donc, ça ne m'est pas indispensable. - les callback, ça, oui, je n'arrête pas de m'en servir. Mais ce n'est pas une exclusivité de la P.F.
@+
MCI
bruno modulix
Do Re Mi chel La Si Do wrote:
Bonsoir !
Tu n'utilises donc ni les décorateurs, ni les expressions de listes, ni même les fonctions de rappel
1) Non, je n'utilise pas les décorateurs. Je préfère décorer moi-même mon sapin de noël. 2) je jubile, à l'idée de lister tes expressions, lorsque tu liras ce message. 3) je ne me rappelle plus quelle fonction j'occupe.
!-)
Sinon : - les décorateurs, c'est marrant, mais, en réalité, ça ne m'apporte pas grand chose.
Le sucre syntaxique, non. Le principe en lui-même, si, beaucoup. Déjà, les classmethod et staticmethod. Ensuite, ça permet de simplifier et factoriser pas mal de choses, par exemple la gestion des ressources
- les listes en intentions, en pratique, je fais d'abord ma routine, classiquement, puis, ensuite, je reécrit en les utilisant. Donc, ça ne m'est pas indispensable.
Tiens, moi j'ai tendance à faire l'inverse (développer la boucle si elle devient trop complexe)
- les callback, ça, oui, je n'arrête pas de m'en servir. Mais ce n'est pas une exclusivité de la P.F.
Non, mais c'est plus utilisé quand c'est naturel dans le langage.
<hs> J'ai mis sur le wiki l'exemple de code pour récupérer le répertoire du script en cours (page CodeDivers, mais ça aurait peut-être dû être dans BonnesPratiques ?), avec une notice concernant la différence de comportement de __file__ entre Windows et Linux, mais tu voudra peut-être détailler un peu plus.
Tu a d'autres exemples de gotchas entre Windows et Linux ? </hs>
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Do Re Mi chel La Si Do wrote:
Bonsoir !
Tu n'utilises donc ni les décorateurs, ni les expressions de listes, ni
même les fonctions de rappel
1) Non, je n'utilise pas les décorateurs. Je préfère décorer moi-même mon
sapin de noël.
2) je jubile, à l'idée de lister tes expressions, lorsque tu liras ce
message.
3) je ne me rappelle plus quelle fonction j'occupe.
!-)
Sinon :
- les décorateurs, c'est marrant, mais, en réalité, ça ne m'apporte pas
grand chose.
Le sucre syntaxique, non. Le principe en lui-même, si, beaucoup. Déjà,
les classmethod et staticmethod. Ensuite, ça permet de simplifier et
factoriser pas mal de choses, par exemple la gestion des ressources
- les listes en intentions, en pratique, je fais d'abord ma routine,
classiquement, puis, ensuite, je reécrit en les utilisant. Donc, ça ne m'est
pas indispensable.
Tiens, moi j'ai tendance à faire l'inverse (développer la boucle si elle
devient trop complexe)
- les callback, ça, oui, je n'arrête pas de m'en servir. Mais ce n'est pas
une exclusivité de la P.F.
Non, mais c'est plus utilisé quand c'est naturel dans le langage.
<hs>
J'ai mis sur le wiki l'exemple de code pour récupérer le répertoire du
script en cours (page CodeDivers, mais ça aurait peut-être dû être dans
BonnesPratiques ?), avec une notice concernant la différence de
comportement de __file__ entre Windows et Linux, mais tu voudra
peut-être détailler un peu plus.
Tu a d'autres exemples de gotchas entre Windows et Linux ?
</hs>
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
Tu n'utilises donc ni les décorateurs, ni les expressions de listes, ni même les fonctions de rappel
1) Non, je n'utilise pas les décorateurs. Je préfère décorer moi-même mon sapin de noël. 2) je jubile, à l'idée de lister tes expressions, lorsque tu liras ce message. 3) je ne me rappelle plus quelle fonction j'occupe.
!-)
Sinon : - les décorateurs, c'est marrant, mais, en réalité, ça ne m'apporte pas grand chose.
Le sucre syntaxique, non. Le principe en lui-même, si, beaucoup. Déjà, les classmethod et staticmethod. Ensuite, ça permet de simplifier et factoriser pas mal de choses, par exemple la gestion des ressources
- les listes en intentions, en pratique, je fais d'abord ma routine, classiquement, puis, ensuite, je reécrit en les utilisant. Donc, ça ne m'est pas indispensable.
Tiens, moi j'ai tendance à faire l'inverse (développer la boucle si elle devient trop complexe)
- les callback, ça, oui, je n'arrête pas de m'en servir. Mais ce n'est pas une exclusivité de la P.F.
Non, mais c'est plus utilisé quand c'est naturel dans le langage.
<hs> J'ai mis sur le wiki l'exemple de code pour récupérer le répertoire du script en cours (page CodeDivers, mais ça aurait peut-être dû être dans BonnesPratiques ?), avec une notice concernant la différence de comportement de __file__ entre Windows et Linux, mais tu voudra peut-être détailler un peu plus.
Tu a d'autres exemples de gotchas entre Windows et Linux ? </hs>
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
