Le 14/06/2010 11:22, Pierre-Alain Dorange a écrit :NicolasP wrote:Je dirais que la plus grande difficulté avec Python c'est d'arriver à
connaitre les bibliothèques standard. Elle sont en nombre impressionnant
et elles sont indispensables.
C'est aussi sa force, le nombre de bibliothèque disponibles permet de
interactions et des choses très complexe avec une mise en oeuvre somem
toute très rapide le plus souvent.
Tout à fait.
Sauf qu'au début (et aussi quand on change de domaine d'application), on
passe beaucoup de temps à trouver la bonne librairie.
En plus, il peut y
avoir plusieurs librairies qui font (presque) la même chose. Le choix
n'est pas forcément évident.
Genre, j'ai besoin de rajouter un thread à mon appli. Chouette, Python a
déjà ce qu'il faut pour ça. Ah oui mais il y a 4 librairies disponibles.
Je prends laquelle ?
Même si 2 semblent pouvoir être éliminées, il en
reste encore 2. Et il faut lire beaucoup pour faire la différence entre
les 2.
Et même parfois, on commence avec l'une et on se rend compte que
l'on tombe sur une impasse. C'est l'autre qu'il fallait choisir.
Attention, je ne dis pas que ce n'est pas bien d'avoir le choix. Si
plusieurs possibilités s'offrent au programmeur, c'est souvent justifié.
Je dis que ce n'est pas évident de s'y retrouver et qu'il faut beaucoup
de temps d'apprentissage avant d'être efficace.
La doc de Python en ligne est d'ailleurs plutôt bonne comme référence
guide mais à mon avis pas assez complète au niveau des exemples
d'utilisation comparatifs, etc. Si on maitrise déjà un sujet et que l'on
cherche une info bien précise, pas de problème. Mais si on explore un
nouveau sujet et que l'on cherche à savoir comment mettre en oeuvre une
librairie, là, c'est moins bien.
Le 14/06/2010 11:22, Pierre-Alain Dorange a écrit :
NicolasP<nicolasp@aaton.com> wrote:
Je dirais que la plus grande difficulté avec Python c'est d'arriver à
connaitre les bibliothèques standard. Elle sont en nombre impressionnant
et elles sont indispensables.
C'est aussi sa force, le nombre de bibliothèque disponibles permet de
interactions et des choses très complexe avec une mise en oeuvre somem
toute très rapide le plus souvent.
Tout à fait.
Sauf qu'au début (et aussi quand on change de domaine d'application), on
passe beaucoup de temps à trouver la bonne librairie.
En plus, il peut y
avoir plusieurs librairies qui font (presque) la même chose. Le choix
n'est pas forcément évident.
Genre, j'ai besoin de rajouter un thread à mon appli. Chouette, Python a
déjà ce qu'il faut pour ça. Ah oui mais il y a 4 librairies disponibles.
Je prends laquelle ?
Même si 2 semblent pouvoir être éliminées, il en
reste encore 2. Et il faut lire beaucoup pour faire la différence entre
les 2.
Et même parfois, on commence avec l'une et on se rend compte que
l'on tombe sur une impasse. C'est l'autre qu'il fallait choisir.
Attention, je ne dis pas que ce n'est pas bien d'avoir le choix. Si
plusieurs possibilités s'offrent au programmeur, c'est souvent justifié.
Je dis que ce n'est pas évident de s'y retrouver et qu'il faut beaucoup
de temps d'apprentissage avant d'être efficace.
La doc de Python en ligne est d'ailleurs plutôt bonne comme référence
guide mais à mon avis pas assez complète au niveau des exemples
d'utilisation comparatifs, etc. Si on maitrise déjà un sujet et que l'on
cherche une info bien précise, pas de problème. Mais si on explore un
nouveau sujet et que l'on cherche à savoir comment mettre en oeuvre une
librairie, là, c'est moins bien.
Le 14/06/2010 11:22, Pierre-Alain Dorange a écrit :NicolasP wrote:Je dirais que la plus grande difficulté avec Python c'est d'arriver à
connaitre les bibliothèques standard. Elle sont en nombre impressionnant
et elles sont indispensables.
C'est aussi sa force, le nombre de bibliothèque disponibles permet de
interactions et des choses très complexe avec une mise en oeuvre somem
toute très rapide le plus souvent.
Tout à fait.
Sauf qu'au début (et aussi quand on change de domaine d'application), on
passe beaucoup de temps à trouver la bonne librairie.
En plus, il peut y
avoir plusieurs librairies qui font (presque) la même chose. Le choix
n'est pas forcément évident.
Genre, j'ai besoin de rajouter un thread à mon appli. Chouette, Python a
déjà ce qu'il faut pour ça. Ah oui mais il y a 4 librairies disponibles.
Je prends laquelle ?
Même si 2 semblent pouvoir être éliminées, il en
reste encore 2. Et il faut lire beaucoup pour faire la différence entre
les 2.
Et même parfois, on commence avec l'une et on se rend compte que
l'on tombe sur une impasse. C'est l'autre qu'il fallait choisir.
Attention, je ne dis pas que ce n'est pas bien d'avoir le choix. Si
plusieurs possibilités s'offrent au programmeur, c'est souvent justifié.
Je dis que ce n'est pas évident de s'y retrouver et qu'il faut beaucoup
de temps d'apprentissage avant d'être efficace.
La doc de Python en ligne est d'ailleurs plutôt bonne comme référence
guide mais à mon avis pas assez complète au niveau des exemples
d'utilisation comparatifs, etc. Si on maitrise déjà un sujet et que l'on
cherche une info bien précise, pas de problème. Mais si on explore un
nouveau sujet et que l'on cherche à savoir comment mettre en oeuvre une
librairie, là, c'est moins bien.
NicolasP a écrit :Le 14/06/2010 11:22, Pierre-Alain Dorange a écrit :NicolasP wrote:Je dirais que la plus grande difficulté avec Python c'est d'arriver à
connaitre les bibliothèques standard. Elle sont en nombre
impressionnant
et elles sont indispensables.
C'est aussi sa force, le nombre de bibliothèque disponibles permet de
interactions et des choses très complexe avec une mise en oeuvre somem
toute très rapide le plus souvent.
Tout à fait.
Sauf qu'au début (et aussi quand on change de domaine d'application),
on passe beaucoup de temps à trouver la bonne librairie.
Mmm ? Pour quelle définition de "beaucoup" ?
En plus, il peut y avoir plusieurs librairies qui font (presque) la
même chose. Le choix n'est pas forcément évident.
Genre, j'ai besoin de rajouter un thread à mon appli. Chouette, Python
a déjà ce qu'il faut pour ça. Ah oui mais il y a 4 librairies
disponibles. Je prends laquelle ?
Un bref coup d'oeil à la doc permet déjà de comprendre qu'il n'y en a en
fait que 2. Les deux autres sont des fallback pour permettre à un
programme de fonctionner en l'absence de thread.Même si 2 semblent pouvoir être éliminées, il en reste encore 2. Et il
faut lire beaucoup pour faire la différence entre les 2.
Heu...
"""
16.3. thread — Multiple threads of control¶
This module provides low-level primitives for working with multiple threads
"""
"""
16.2. threading — Higher-level threading interface¶
This module constructs higher-level threading interfaces on top of the
lower level thread module
"""
Ca donne quand même déjà une idée, non ?
Et même parfois, on commence avec l'une et on se rend compte que l'on
tombe sur une impasse. C'est l'autre qu'il fallait choisir.
Avec l'une étant un wrapper autour de la seconde, je ne vois pas trop
sur quelle "impasse" tu pourrais tomber ??? Enfin bon, j'ai rarement mis
les mains dans les thread moi-même (rarement eu le besoin), donc si tu a
un example...
Pour la majorité des fonctionnalités, il y a un et un seul choix. Pour
certaines fonctionnalités, il y a effectivement plusieurs choix
possibles, soit qu'une implémentation moins complète ou moins puissante
ait été conservée pour des raison de compatibilité (et dans ce cas c'est
généralement mentionné), soit qu'il fasse sens d'avoir une (ou plus)
alternatives (par example pour le parsing XML / HTML / SGML).
Attention, je ne dis pas que ce n'est pas bien d'avoir le choix. Si
plusieurs possibilités s'offrent au programmeur, c'est souvent
justifié. Je dis que ce n'est pas évident de s'y retrouver et qu'il
faut beaucoup de temps d'apprentissage avant d'être efficace.
Le problème se pose quelque soit le langage, à la différence près que
dans certains autres langages la fonctionnalité n'existe pas dans la
bibliothèque standard, ce qui rend le choix bien plus difficile.
Pas que la stdlib Python soit parfaite, loin s'en faut, et je peux
confirmer que dans quelques cas il faut effectivement lire un peu (ou
plus) de doc et éventuellement faire quelques tests avant de déterminer
quel module choisir pour une certaine fonctionnalité, mais quand je
compare avec d'autres langages je trouve que c'est quand même plutôt un
peu au dessus de la moyenne.La doc de Python en ligne est d'ailleurs plutôt bonne comme référence
guide mais à mon avis pas assez complète au niveau des exemples
d'utilisation comparatifs, etc. Si on maitrise déjà un sujet et que
l'on cherche une info bien précise, pas de problème. Mais si on
explore un nouveau sujet et que l'on cherche à savoir comment mettre
en oeuvre une librairie, là, c'est moins bien.
Le problème ici est plus un manque de connaissance du domaine qu'un
"manque" dans la doc, non ? Ou tu penses à autre chose ?
NicolasP a écrit :
Le 14/06/2010 11:22, Pierre-Alain Dorange a écrit :
NicolasP<nicolasp@aaton.com> wrote:
Je dirais que la plus grande difficulté avec Python c'est d'arriver à
connaitre les bibliothèques standard. Elle sont en nombre
impressionnant
et elles sont indispensables.
C'est aussi sa force, le nombre de bibliothèque disponibles permet de
interactions et des choses très complexe avec une mise en oeuvre somem
toute très rapide le plus souvent.
Tout à fait.
Sauf qu'au début (et aussi quand on change de domaine d'application),
on passe beaucoup de temps à trouver la bonne librairie.
Mmm ? Pour quelle définition de "beaucoup" ?
En plus, il peut y avoir plusieurs librairies qui font (presque) la
même chose. Le choix n'est pas forcément évident.
Genre, j'ai besoin de rajouter un thread à mon appli. Chouette, Python
a déjà ce qu'il faut pour ça. Ah oui mais il y a 4 librairies
disponibles. Je prends laquelle ?
Un bref coup d'oeil à la doc permet déjà de comprendre qu'il n'y en a en
fait que 2. Les deux autres sont des fallback pour permettre à un
programme de fonctionner en l'absence de thread.
Même si 2 semblent pouvoir être éliminées, il en reste encore 2. Et il
faut lire beaucoup pour faire la différence entre les 2.
Heu...
"""
16.3. thread — Multiple threads of control¶
This module provides low-level primitives for working with multiple threads
"""
"""
16.2. threading — Higher-level threading interface¶
This module constructs higher-level threading interfaces on top of the
lower level thread module
"""
Ca donne quand même déjà une idée, non ?
Et même parfois, on commence avec l'une et on se rend compte que l'on
tombe sur une impasse. C'est l'autre qu'il fallait choisir.
Avec l'une étant un wrapper autour de la seconde, je ne vois pas trop
sur quelle "impasse" tu pourrais tomber ??? Enfin bon, j'ai rarement mis
les mains dans les thread moi-même (rarement eu le besoin), donc si tu a
un example...
Pour la majorité des fonctionnalités, il y a un et un seul choix. Pour
certaines fonctionnalités, il y a effectivement plusieurs choix
possibles, soit qu'une implémentation moins complète ou moins puissante
ait été conservée pour des raison de compatibilité (et dans ce cas c'est
généralement mentionné), soit qu'il fasse sens d'avoir une (ou plus)
alternatives (par example pour le parsing XML / HTML / SGML).
Attention, je ne dis pas que ce n'est pas bien d'avoir le choix. Si
plusieurs possibilités s'offrent au programmeur, c'est souvent
justifié. Je dis que ce n'est pas évident de s'y retrouver et qu'il
faut beaucoup de temps d'apprentissage avant d'être efficace.
Le problème se pose quelque soit le langage, à la différence près que
dans certains autres langages la fonctionnalité n'existe pas dans la
bibliothèque standard, ce qui rend le choix bien plus difficile.
Pas que la stdlib Python soit parfaite, loin s'en faut, et je peux
confirmer que dans quelques cas il faut effectivement lire un peu (ou
plus) de doc et éventuellement faire quelques tests avant de déterminer
quel module choisir pour une certaine fonctionnalité, mais quand je
compare avec d'autres langages je trouve que c'est quand même plutôt un
peu au dessus de la moyenne.
La doc de Python en ligne est d'ailleurs plutôt bonne comme référence
guide mais à mon avis pas assez complète au niveau des exemples
d'utilisation comparatifs, etc. Si on maitrise déjà un sujet et que
l'on cherche une info bien précise, pas de problème. Mais si on
explore un nouveau sujet et que l'on cherche à savoir comment mettre
en oeuvre une librairie, là, c'est moins bien.
Le problème ici est plus un manque de connaissance du domaine qu'un
"manque" dans la doc, non ? Ou tu penses à autre chose ?
NicolasP a écrit :Le 14/06/2010 11:22, Pierre-Alain Dorange a écrit :NicolasP wrote:Je dirais que la plus grande difficulté avec Python c'est d'arriver à
connaitre les bibliothèques standard. Elle sont en nombre
impressionnant
et elles sont indispensables.
C'est aussi sa force, le nombre de bibliothèque disponibles permet de
interactions et des choses très complexe avec une mise en oeuvre somem
toute très rapide le plus souvent.
Tout à fait.
Sauf qu'au début (et aussi quand on change de domaine d'application),
on passe beaucoup de temps à trouver la bonne librairie.
Mmm ? Pour quelle définition de "beaucoup" ?
En plus, il peut y avoir plusieurs librairies qui font (presque) la
même chose. Le choix n'est pas forcément évident.
Genre, j'ai besoin de rajouter un thread à mon appli. Chouette, Python
a déjà ce qu'il faut pour ça. Ah oui mais il y a 4 librairies
disponibles. Je prends laquelle ?
Un bref coup d'oeil à la doc permet déjà de comprendre qu'il n'y en a en
fait que 2. Les deux autres sont des fallback pour permettre à un
programme de fonctionner en l'absence de thread.Même si 2 semblent pouvoir être éliminées, il en reste encore 2. Et il
faut lire beaucoup pour faire la différence entre les 2.
Heu...
"""
16.3. thread — Multiple threads of control¶
This module provides low-level primitives for working with multiple threads
"""
"""
16.2. threading — Higher-level threading interface¶
This module constructs higher-level threading interfaces on top of the
lower level thread module
"""
Ca donne quand même déjà une idée, non ?
Et même parfois, on commence avec l'une et on se rend compte que l'on
tombe sur une impasse. C'est l'autre qu'il fallait choisir.
Avec l'une étant un wrapper autour de la seconde, je ne vois pas trop
sur quelle "impasse" tu pourrais tomber ??? Enfin bon, j'ai rarement mis
les mains dans les thread moi-même (rarement eu le besoin), donc si tu a
un example...
Pour la majorité des fonctionnalités, il y a un et un seul choix. Pour
certaines fonctionnalités, il y a effectivement plusieurs choix
possibles, soit qu'une implémentation moins complète ou moins puissante
ait été conservée pour des raison de compatibilité (et dans ce cas c'est
généralement mentionné), soit qu'il fasse sens d'avoir une (ou plus)
alternatives (par example pour le parsing XML / HTML / SGML).
Attention, je ne dis pas que ce n'est pas bien d'avoir le choix. Si
plusieurs possibilités s'offrent au programmeur, c'est souvent
justifié. Je dis que ce n'est pas évident de s'y retrouver et qu'il
faut beaucoup de temps d'apprentissage avant d'être efficace.
Le problème se pose quelque soit le langage, à la différence près que
dans certains autres langages la fonctionnalité n'existe pas dans la
bibliothèque standard, ce qui rend le choix bien plus difficile.
Pas que la stdlib Python soit parfaite, loin s'en faut, et je peux
confirmer que dans quelques cas il faut effectivement lire un peu (ou
plus) de doc et éventuellement faire quelques tests avant de déterminer
quel module choisir pour une certaine fonctionnalité, mais quand je
compare avec d'autres langages je trouve que c'est quand même plutôt un
peu au dessus de la moyenne.La doc de Python en ligne est d'ailleurs plutôt bonne comme référence
guide mais à mon avis pas assez complète au niveau des exemples
d'utilisation comparatifs, etc. Si on maitrise déjà un sujet et que
l'on cherche une info bien précise, pas de problème. Mais si on
explore un nouveau sujet et que l'on cherche à savoir comment mettre
en oeuvre une librairie, là, c'est moins bien.
Le problème ici est plus un manque de connaissance du domaine qu'un
"manque" dans la doc, non ? Ou tu penses à autre chose ?
Le 14/06/2010 15:13, Bruno Desthuilliers a écrit :NicolasP a écrit :Le 14/06/2010 11:22, Pierre-Alain Dorange a écrit :NicolasP wrote:Je dirais que la plus grande difficulté avec Python c'est d'arriver à
connaitre les bibliothèques standard. Elle sont en nombre
impressionnant
et elles sont indispensables.
C'est aussi sa force, le nombre de bibliothèque disponibles permet de
interactions et des choses très complexe avec une mise en oeuvre somem
toute très rapide le plus souvent.
Tout à fait.
Sauf qu'au début (et aussi quand on change de domaine d'application),
on passe beaucoup de temps à trouver la bonne librairie.
Mmm ? Pour quelle définition de "beaucoup" ?
Ben... Beaucoup
Le 14/06/2010 15:13, Bruno Desthuilliers a écrit :
NicolasP a écrit :
Le 14/06/2010 11:22, Pierre-Alain Dorange a écrit :
NicolasP<nicolasp@aaton.com> wrote:
Je dirais que la plus grande difficulté avec Python c'est d'arriver à
connaitre les bibliothèques standard. Elle sont en nombre
impressionnant
et elles sont indispensables.
C'est aussi sa force, le nombre de bibliothèque disponibles permet de
interactions et des choses très complexe avec une mise en oeuvre somem
toute très rapide le plus souvent.
Tout à fait.
Sauf qu'au début (et aussi quand on change de domaine d'application),
on passe beaucoup de temps à trouver la bonne librairie.
Mmm ? Pour quelle définition de "beaucoup" ?
Ben... Beaucoup
Le 14/06/2010 15:13, Bruno Desthuilliers a écrit :NicolasP a écrit :Le 14/06/2010 11:22, Pierre-Alain Dorange a écrit :NicolasP wrote:Je dirais que la plus grande difficulté avec Python c'est d'arriver à
connaitre les bibliothèques standard. Elle sont en nombre
impressionnant
et elles sont indispensables.
C'est aussi sa force, le nombre de bibliothèque disponibles permet de
interactions et des choses très complexe avec une mise en oeuvre somem
toute très rapide le plus souvent.
Tout à fait.
Sauf qu'au début (et aussi quand on change de domaine d'application),
on passe beaucoup de temps à trouver la bonne librairie.
Mmm ? Pour quelle définition de "beaucoup" ?
Ben... Beaucoup
On 14-06-2010, NicolasP wrote:Le 14/06/2010 15:13, Bruno Desthuilliers a écrit :NicolasP a écrit :Le 14/06/2010 11:22, Pierre-Alain Dorange a écrit :NicolasP wrote:Je dirais que la plus grande difficulté avec Python c'est d'arriver à
connaitre les bibliothèques standard. Elle sont en nombre
impressionnant
et elles sont indispensables.
C'est aussi sa force, le nombre de bibliothèque disponibles permet de
interactions et des choses très complexe avec une mise en oeuvre somem
toute très rapide le plus souvent.
Tout à fait.
Sauf qu'au début (et aussi quand on change de domaine d'application),
on passe beaucoup de temps à trouver la bonne librairie.
Mmm ? Pour quelle définition de "beaucoup" ?
Ben... Beaucoup
Je suis assez d'accord avec Nicolas, on tends progressivement à perdre
le côté "There should be one-- and preferably only one --obvious way to
do it". Y a qu'à voir le nombre de frameworks web, les librairies xml,
les librairies multi-process. C'est général. Bruno a raison aussi, c'est
peut-être moins pire en python.
Plus on a voulu se rapprocher de windows plus la philosophie unix s'est
fourvoyée. Rappelons que le terme unix signifie ne faire qu'une chose
à la fois mais bien.
Je trouve dommage qu'il n'y ait pas eu plus de ménage de fait avec
python3, quitte à y passer plus de temps
vu que de toutes façon il n'est
presque pas utilisé.
On 14-06-2010, NicolasP wrote:
Le 14/06/2010 15:13, Bruno Desthuilliers a écrit :
NicolasP a écrit :
Le 14/06/2010 11:22, Pierre-Alain Dorange a écrit :
NicolasP<nicolasp@aaton.com> wrote:
Je dirais que la plus grande difficulté avec Python c'est d'arriver à
connaitre les bibliothèques standard. Elle sont en nombre
impressionnant
et elles sont indispensables.
C'est aussi sa force, le nombre de bibliothèque disponibles permet de
interactions et des choses très complexe avec une mise en oeuvre somem
toute très rapide le plus souvent.
Tout à fait.
Sauf qu'au début (et aussi quand on change de domaine d'application),
on passe beaucoup de temps à trouver la bonne librairie.
Mmm ? Pour quelle définition de "beaucoup" ?
Ben... Beaucoup
Je suis assez d'accord avec Nicolas, on tends progressivement à perdre
le côté "There should be one-- and preferably only one --obvious way to
do it". Y a qu'à voir le nombre de frameworks web, les librairies xml,
les librairies multi-process. C'est général. Bruno a raison aussi, c'est
peut-être moins pire en python.
Plus on a voulu se rapprocher de windows plus la philosophie unix s'est
fourvoyée. Rappelons que le terme unix signifie ne faire qu'une chose
à la fois mais bien.
Je trouve dommage qu'il n'y ait pas eu plus de ménage de fait avec
python3, quitte à y passer plus de temps
vu que de toutes façon il n'est
presque pas utilisé.
On 14-06-2010, NicolasP wrote:Le 14/06/2010 15:13, Bruno Desthuilliers a écrit :NicolasP a écrit :Le 14/06/2010 11:22, Pierre-Alain Dorange a écrit :NicolasP wrote:Je dirais que la plus grande difficulté avec Python c'est d'arriver à
connaitre les bibliothèques standard. Elle sont en nombre
impressionnant
et elles sont indispensables.
C'est aussi sa force, le nombre de bibliothèque disponibles permet de
interactions et des choses très complexe avec une mise en oeuvre somem
toute très rapide le plus souvent.
Tout à fait.
Sauf qu'au début (et aussi quand on change de domaine d'application),
on passe beaucoup de temps à trouver la bonne librairie.
Mmm ? Pour quelle définition de "beaucoup" ?
Ben... Beaucoup
Je suis assez d'accord avec Nicolas, on tends progressivement à perdre
le côté "There should be one-- and preferably only one --obvious way to
do it". Y a qu'à voir le nombre de frameworks web, les librairies xml,
les librairies multi-process. C'est général. Bruno a raison aussi, c'est
peut-être moins pire en python.
Plus on a voulu se rapprocher de windows plus la philosophie unix s'est
fourvoyée. Rappelons que le terme unix signifie ne faire qu'une chose
à la fois mais bien.
Je trouve dommage qu'il n'y ait pas eu plus de ménage de fait avec
python3, quitte à y passer plus de temps
vu que de toutes façon il n'est
presque pas utilisé.
Tout d'abord, merci à tous pour vos réponses encourageantes.
Tout d'abord, merci à tous pour vos réponses encourageantes.
Tout d'abord, merci à tous pour vos réponses encourageantes.
Pascal Hambourg a écrit :Tout d'abord, merci à tous pour vos réponses encourageantes.
Juste un dernier mot sur ce fil intéressante (merci a tous), comme quoi
fclp is not dead (tant mieux et encore merci a tous)
L'objet est déroutant, quand on vient d'un langage fonctionnel
et en gros j'ai eu le déclic grace a perl et a sa manière
particulière de faire de l'objet
En perl un objet est une "variable" (association nom espace memoire)
comme les autres sauf qu'elle est "bénie" => bless
A partir de la j'ai mieux compris certaines choses ...
Pascal Hambourg a écrit :
Tout d'abord, merci à tous pour vos réponses encourageantes.
Juste un dernier mot sur ce fil intéressante (merci a tous), comme quoi
fclp is not dead (tant mieux et encore merci a tous)
L'objet est déroutant, quand on vient d'un langage fonctionnel
et en gros j'ai eu le déclic grace a perl et a sa manière
particulière de faire de l'objet
En perl un objet est une "variable" (association nom espace memoire)
comme les autres sauf qu'elle est "bénie" => bless
A partir de la j'ai mieux compris certaines choses ...
Pascal Hambourg a écrit :Tout d'abord, merci à tous pour vos réponses encourageantes.
Juste un dernier mot sur ce fil intéressante (merci a tous), comme quoi
fclp is not dead (tant mieux et encore merci a tous)
L'objet est déroutant, quand on vient d'un langage fonctionnel
et en gros j'ai eu le déclic grace a perl et a sa manière
particulière de faire de l'objet
En perl un objet est une "variable" (association nom espace memoire)
comme les autres sauf qu'elle est "bénie" => bless
A partir de la j'ai mieux compris certaines choses ...
Le Fri, 11 Jun 2010 14:09:33 +0200, Bruno Desthuilliers a écrit :chris a écrit :
SAlut,
sincèrement tu as développe en C et php mais python t'interresse moi je
dirais que tu es récupérable
Oh, un fanboy...
Dis, à ton avis, c'est écrit en quoi, Python ?-)
L'implémentation la plus courante est écrite en C (Cpython).
Mais il existe aussi Jython, et en truc qui fout le vertige : PyPy, un
Python écrit dans un sous-ensemble de python, lui-même écrit...
Sur certains cas, le python écrit en python va plus vite que le python
écrit en C ! Et il en existe une version "stackless", sans GIL
qq détails en anglais à :
http://lwn.net/Articles/387561/
Le Fri, 11 Jun 2010 14:09:33 +0200, Bruno Desthuilliers a écrit :
chris a écrit :
SAlut,
sincèrement tu as développe en C et php mais python t'interresse moi je
dirais que tu es récupérable
Oh, un fanboy...
Dis, à ton avis, c'est écrit en quoi, Python ?-)
L'implémentation la plus courante est écrite en C (Cpython).
Mais il existe aussi Jython, et en truc qui fout le vertige : PyPy, un
Python écrit dans un sous-ensemble de python, lui-même écrit...
Sur certains cas, le python écrit en python va plus vite que le python
écrit en C ! Et il en existe une version "stackless", sans GIL
qq détails en anglais à :
http://lwn.net/Articles/387561/
Le Fri, 11 Jun 2010 14:09:33 +0200, Bruno Desthuilliers a écrit :chris a écrit :
SAlut,
sincèrement tu as développe en C et php mais python t'interresse moi je
dirais que tu es récupérable
Oh, un fanboy...
Dis, à ton avis, c'est écrit en quoi, Python ?-)
L'implémentation la plus courante est écrite en C (Cpython).
Mais il existe aussi Jython, et en truc qui fout le vertige : PyPy, un
Python écrit dans un sous-ensemble de python, lui-même écrit...
Sur certains cas, le python écrit en python va plus vite que le python
écrit en C ! Et il en existe une version "stackless", sans GIL
qq détails en anglais à :
http://lwn.net/Articles/387561/
Bruno Desthuilliers a écrit :chris a écrit :
SAlut,
sincèrement tu as développe en C et php mais python t'interresse
moi je dirais que tu es récupérable
Oh, un fanboy...
Ah ca oui et j'assume :)
Dis, à ton avis, c'est écrit en quoi, Python ?-)
De base en C mais en prenant exemple sur les poules et leurs oeufs
(comme quoi l'etre humain n'a pas inventé grand chose ...)
il est écrit aussi en python.
<humour>
Je rajouterais que le C est un langage de bas niveau ... :)
</humour>
Bruno Desthuilliers a écrit :
chris a écrit :
SAlut,
sincèrement tu as développe en C et php mais python t'interresse
moi je dirais que tu es récupérable
Oh, un fanboy...
Ah ca oui et j'assume :)
Dis, à ton avis, c'est écrit en quoi, Python ?-)
De base en C mais en prenant exemple sur les poules et leurs oeufs
(comme quoi l'etre humain n'a pas inventé grand chose ...)
il est écrit aussi en python.
<humour>
Je rajouterais que le C est un langage de bas niveau ... :)
</humour>
Bruno Desthuilliers a écrit :chris a écrit :
SAlut,
sincèrement tu as développe en C et php mais python t'interresse
moi je dirais que tu es récupérable
Oh, un fanboy...
Ah ca oui et j'assume :)
Dis, à ton avis, c'est écrit en quoi, Python ?-)
De base en C mais en prenant exemple sur les poules et leurs oeufs
(comme quoi l'etre humain n'a pas inventé grand chose ...)
il est écrit aussi en python.
<humour>
Je rajouterais que le C est un langage de bas niveau ... :)
</humour>
