Avantages de Python ???

Version imprimable

02/08/2005, 11h32
Royd938

Avantages de Python ???

Bonjour à tous,

Quel est l'avantage d'avoir un langage non typé??? Pour ceux qui ont déjà coder d'important projet en Python, vous n'avez pas l'impression que cela pose des problèmes de clarté??? Est-ce vraiment une facilité?
06/08/2005, 00h26
doof

Salut, Python est typé, il ne faut pas confondre "non typé" et "typé dynamiquement".

De plus, le transtypage n'est pas dynamique, on pourait donc même dire qu'il est fortement typé.

Pour ma part, je n'y vois que des avantages (typage implicite) en évitant les erreurs de certains autres langages (transtypage explicite).
06/08/2005, 09h16
miminum

Je débute en Python donc mes propos sont à prendre avec précaution. Il me semble - je l'ai lu quelquepart - que l'absence de type à la déclaration permet d'obtenir une généricité dans les méthodes et les fonctions, ce qui est bienvenu en orientation objet et nécessite un travail supplémentaire dans d'autres langages. Par contre, revers de la médaille, beaucoup d'erreurs qui sont facilement décellable à la compilation par un langage statiquement typé ne sont découvertes qu'à l'éxecution par Python. Ceci implique d'autres habitudes de programmation.

Pour moi les gros avantages de Python sont :

- productivité : c'est probablement le langage le moins verbeux;

- clarté du code : la syntaxe est parmi les plus lisibles

- développement dynamique : tout est dynamique et interprété

Enfin le gros inconvénient est la lenteur d'éxecution. Python est un des langages les plus lents à l'éxecution. Mais il est toujours possible d'identifier les goulots d'étranglement (qui en général représentent une petite partie du code) et de les recoder en C ou C++ et de les lier au code Python.
06/08/2005, 09h41
Guigui_

Citation:

Envoyé par miminum

Enfin le gros inconvénient est la lenteur d'éxecution. Python est un des langages les plus lents à l'éxecution. Mais il est toujours possible d'identifier les goulots d'étranglement (qui en général représentent une petite partie du code) et de les recoder en C ou C++ et de les lier au code Python.

Bon, la lenteur d'un code ne vient en général pas du langage utilisé mais plutôt de la façon de programmer. Et Python est loin d'être lent (si l'on pense à utiliser les librairies à notre disposition)
Moi, je n'ai aucun souci avec mes programmes python qui ont besoin d'une grosse puissance de calcul (traitement d'images).
06/08/2005, 10h17
miminum

Que tu n'aies pas de problèmes de lenteur dans tes programmes en Python n'atteste en rien que le langage soit rapide (ou plutôt que l'implémentation de l'interpréteur le soit). Je fais souvent beaucoup de code en VBA sans avoir de problèmes de lenteur mais je n'affirme pas pour autant que le code produit est rapide. A mon avis si tu n'as pas de problèmes avec tes traitements d'images c'est que tu fais appel à des librairies qui ne sont pas entièrement programmées en Python (PIL dans ton cas peut être).
Je me base sur des benchmarks d'algo programmés dans divers langages et qui montrent que Python est un des langages qui produit le code parmi les plus lents (le facteur peut être de 1 à 100 comparé au C). Mais encore une fois évidement ce n'est pas forcément un problème. D'une part on peut utiliser des langages plus rapides pour certaines parties et d'autre part avec nos machines actuelles à 3 GHz les questions de vitesses sont de moins en moins préoccupantes.
06/08/2005, 14h23
Guigui_

Citation:

Envoyé par miminum

Que tu n'aies pas de problèmes de lenteur dans tes programmes en Python n'atteste en rien que le langage soit rapide (ou plutôt que l'implémentation de l'interpréteur le soit). Je fais souvent beaucoup de code en VBA sans avoir de problèmes de lenteur mais je n'affirme pas pour autant que le code produit est rapide.

J'insiste sur le fait que les problèmes de lenteur ne viennent en général pas du langage mais du programmeur. Sinon, heureusement que Python est plus lent que le C, vu que ce n'est qu'une surcouche du C et un langage interprété.

Citation:

Envoyé par miminum

A mon avis si tu n'as pas de problèmes avec tes traitements d'images c'est que tu fais appel à des librairies qui ne sont pas entièrement programmées en Python (PIL dans ton cas peut être).

J'utilise PIL effectivement (enfin très peu car au niveau traitement d'images, y'a rien du tout dedans) mais surtout numarray. Après le fait qu'elles soit programmé ou non en python, peu importe vu que moi, je les attaque uniquement par du python. De toute façon, il est déconseillé quelque soit le langage de réinventer la roue
Et j'utilise égalemet mes propres librairies de traitement d'images (qui sont programmées exclusivement en python :wink: ). Après c'est sûr que si tu utilises le C avec un usage intensif des pointeurs, ca ira plus vite (mais bon, le code sera complètement illisible).

Citation:

Envoyé par miminum

Je me base sur des benchmarks d'algo programmés dans divers langages et qui montrent que Python est un des langages qui produit le code parmi les plus lents (le facteur peut être de 1 à 100 comparé au C).

Alors les benchmarks réalisés avec Python 2.4 (ou même qui ne date pas de plus de 2 ans), j'aimerai bien les voir.
Et ce qui compte, n'est pas la rapidité du langage pur mais de ton prog. (Et Python n'est qu'une surcouche de C de toute façon). Pour l'accélération des progs, j'utilise la bibliothèques Psyco qui fait une compilation en C, n'empêche, ce que je code, ca reste du Python.
Donc je ne sais pas combien de temps ca aurait mis si j'avais tout programmé en C, mais je doute que le gain soit si énorme que ça (surtout si je n'utilisais aucune librairie annexe)

Citation:

Envoyé par miminum

Mais encore une fois évidement ce n'est pas forcément un problème. D'une part on peut utiliser des langages plus rapides pour certaines parties et d'autre part avec nos machines actuelles à 3 GHz les questions de vitesses sont de moins en moins préoccupantes.

Rien ne t'empêche de programmer des bouts de code dans d'autres langages pour gagner un peu en rapidité mais ca arrive tellement peu souvent qu'il est inutile d'en faire mention<;
06/08/2005, 15h05
miminum

Citation:

J'insiste sur le fait que les problèmes de lenteur ne viennent en général pas du langage mais du programmeur. Sinon, heureusement que Python est plus lent que le C, vu que ce n'est qu'une surcouche du C et un langage interprété.

Python n'est pas une surcouche du C. Simplement l'interpréteur PythonC, le plus utilisé est programmé en C. Rien à voir avec une surcouche : terme inadapté.

Citation:

J'utilise PIL effectivement (enfin très peu car au niveau traitement d'images, y'a rien du tout dedans) mais surtout numarray. Après le fait qu'elles soit programmé ou non en python, peu importe vu que moi, je les attaque uniquement par du python. De toute façon, il est déconseillé quelque soit le langage de réinventer la roue

Tu les attaques en Python, certes, encore heureux :)

Où ai-je dis qu'il fallait réinventer la roue ?

Citation:

Et j'utilise égalemet mes propres librairies de traitement d'images (qui sont programmées exclusivement en python Wink ). Après c'est sûr que si tu utilises le C avec un usage intensif des pointeurs, ca ira plus vite (mais bon, le code sera complètement illisible).

Un code avec usage intensif des pointeurs n'est pas forcément illisible.

Citation:

Alors les benchmarks réalisés avec Python 2.4 (ou même qui ne date pas de plus de 2 ans), j'aimerai bien les voir.

Voici : http://shootout.alioth.debian.org/
Tu as même les codes sources avec.

Tu es modérateur ou Ayatollah ? Je commence à comprendre pourquoi le forum est désert. Ensuite figure toi que si je suis ici c'est que je trouve Python très très intéressant, ce qui ne m'empêche pas de garder un esprit critique et mesuré. J'ai l'impression de parler avec des jeunes fanatiques du Java.

Citation:

Pour l'accélération des progs, j'utilise la bibliothèques Psyco qui fait une compilation en C, n'empêche, ce que je code, ca reste du Python.

Psyco ça donne du x2 à x4 en général, pas du fois 50. Ce qui n'enlève rien à l'intérêt de Psyco car c'est très appréciable de gagner autant sans avoir à retoucher au code.

Citation:

Donc je ne sais pas combien de temps ca aurait mis si j'avais tout programmé en C, mais je doute que le gain soit si énorme que ça (surtout si je n'utilisais aucune librairie annexe)

Encore une fois tu me prêtes des propos que je n'ai pas tenu. En aucune manière je n'ai signifié qu'il fallait tout programmer en C. J'ai dit, et je persiste, que dans des cas particuliers et identifiés, programmer une petite bibliothèque en C (sans réinventer la roue) ou en utiliser une déjà faite dans un autre langage permettait de résoudre le problème qui de ce fait n'existe plus. Mes propos sont-ils si sujets à interprétation ?

Citation:

Rien ne t'empêche de programmer des bouts de code dans d'autres langages pour gagner un peu en rapidité mais ca arrive tellement peu souvent qu'il est inutile d'en faire mention.

Argument farfelu. Tu programmes des applis client qui se satisfont de la "pseudo lenteur" de Python, soit. Maintenant si tu programmes du code coté serveur qui va tourner en 1 seconde au lieu de 30 milli le serveur risque de faire la gueule s'il est sollicité. Ensuite tu te rendrais compte que quelques routines peuvent être implémentées en C et liées à Python pour arriver à 60 milli. A mon avis tu n'hésiterais pas une seconde.

Citation:

Envoyé par miminum

Voici : http://shootout.alioth.debian.org/
Tu as même les codes sources avec.

cool!!!, je ne connaissais pas. Elles sont pas trop mal faite. Je les ai pas toute parcouru mais en regardant une, j'aurai programmé autrement.
Par exemple: harmonic benchmark avec Python Psyco:
leur programme (j'ai juste rajouté le module time pour les mesures de temps
Code:

1 2 3 4 5 6 7 8 9 10 11 12 import sys, psyco import time psyco.full() def main(): s = float(0) for i in range(int(sys.argv[1])): s = s + 1/(float(i+1)) print "%.9f" % s a=time.clock() main() b=time.clock() print b-a
temps de calcul: je mesure à peu près 5''3 pour 10 millions de nombres (sur un p4 3Ghz, 512Mo)

Je change juste un petit truc:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 import sys, psyco import time psyco.full() def main(): s = float(0) for i in range(int(sys.argv[1])): s = s + 1.0/(i+1) print "%.9f" % s a=time.clock() main() b=time.clock() print b-a raw_input("")
je tombe à 0''8

Bon après, tu en tires la conclusion que tu veux :idea:

Citation:

Envoyé par miminum

Tu es modérateur ou Ayatollah ? Je commence à comprendre pourquoi le forum est désert. Ensuite figure toi que si je suis ici c'est que je trouve Python très très intéressant, ce qui ne m'empêche pas de garder un esprit critique et mesuré.

Ce qui me gênait simplement dans ton premier post, c'est que tu disais que le gros inconviénement de Python, c'était sa lenteur alors que beaucoup de programmeurs le clament haut et fort sans jamais avoir écrit une ligne de Python.
Bon, je ne suis pas d'accord c'est tout. Certes, c'est bien plus lent que le C si on se contente d'une programmation brute, mais il y a beaucoup de solutions pour accélérer le code (librairies optimisées à disposition, compilation avec psyco). Et il faut penser qu'en Python, il n'y a pas de compilateur qui peut faire les optimisatons à notre place. Donc dès qu'il y a des boucles, il faut bien penser à sortir tout ce qui peut l'être (je dis ça en notant quelques optimisations possibles dans les boucles des benchmarks :wink: )

06/08/2005, 17h49
miminum

Je me suis emporté un peu, j'avoue et je m'en excuse. Je pensais que tu étais de mauvaise foi et ça m'irritait.
Apparement tu maîtrises bien la syntaxe, personnellement je débute en Python donc j'aurais du mal à juger tes modifications. Je pense que tu pourrais soumettre ton code au site, peut-être intègreront-ils tes modifs.

Pour en revenir au sujet de la "lenteur", c'est une appréciation RELATIVE aux autres langages, car pour moi la question était de comparer Python aux autres langages. Maintenant dans l'ABSOLU cette différence de vitesse ne se fait bien entendu pas sentir dans 99% des cas certainement.

En fait je me suis intéressé plus particulièrement à ce point (avec celui du déploiement, j'ai vu qu'un autre topic en parle) car j'ai eu envie de commencer à tout basculer sur Python tellement ce langage m'attire. Avec les années de développement j'ai de moins en moins de temps à perdre avec la syntaxe d'un langage et Python me laisse espérer une grande convivialité de codage. Je me suis donc intéressé au seul point qui pouvait éventuellement poser des problèmes sur certains projets qui demandent un peu de puissance et de réactivité, et la très facile liaison avec le C m'a convaincu que je pourrai toujours faire face à ce genre de problème s'il se présentait. C'est surtout un problème d'anticipation pour éviter, après des mois de développement, de se retouver comme un con à foutre un projet en l'air à cause ça.

Cordialement
06/08/2005, 17h56
miminum

En fait je viens de regarder ta modif. Es-tu certain que les valeurs en sortie sont les mêmes ? Parce qu'à mon avis le cast en float n'est pas là pour rien. Bon toujours pareil, je suis pas assez connaisseur de la syntaxe, c'est juste une question.
06/08/2005, 18h02
miminum

Oups, j'avais pas bien regardé :

Tu as changé 1 / (float (i+1) ) par 1.0 / (i+1).

Autant pour moi.
06/08/2005, 18h21
Guigui_

Citation:

Envoyé par miminum

Je me suis emporté un peu, j'avoue et je m'en excuse. Je pensais que tu étais de mauvaise foi et ça m'irritait.
Apparement tu maîtrises bien la syntaxe, personnellement je débute en Python donc j'aurais du mal à juger tes modifications. Je pense que tu pourrais soumettre ton code au site, peut-être intègreront-ils tes modifs.

C'est pour ça que je prends bien garde à tout ce que je dis :wink: (et encore là, je n'étais pas totalement sûr, je ne suis pas un expert de Python et encore moins des autres langages, je ne suis qu'un programmeur de haut niveau (donc, je ne maîtrise pas du tout les subtilités qui peuvent se cacher dans les concepts des langages)

Citation:

Envoyé par miminum

Pour en revenir au sujet de la "lenteur", c'est une appréciation RELATIVE aux autres langages, car pour moi la question était de comparer Python aux autres langages. Maintenant dans l'ABSOLU cette différence de vitesse ne se fait bien entendu pas sentir dans 99% des cas certainement.

Un des avantages de Python, c'est de fournir de multpiles bibliothèques optimisées facilement utilisables. Et la façon de programmer joue énormément, surtout en Python où il n'y a pas de compilateur pour optimiser à notre place.
On y gagnera plus à changer sa bécanne plutôt qu'a changer de langage de programmation.

Citation:

Envoyé par miminum

En fait je me suis intéressé plus particulièrement à ce point (avec celui du déploiement, j'ai vu qu'un autre topic en parle) car j'ai eu envie de commencer à tout basculer sur Python tellement ce langage m'attire. Avec les années de développement j'ai de moins en moins de temps à perdre avec la syntaxe d'un langage et Python me laisse espérer une grande convivialité de codage.

C'est exactement pour cela que je suis resté à Python une fois que l'on me l'a fait découvrir (bon ça fait qu'un peu plus d'un an que je programme en Python).

Citation:

Envoyé par miminum

Je me suis donc intéressé au seul point qui pouvait éventuellement poser des problèmes sur certains projets qui demandent un peu de puissance et de réactivité, et la très facile liaison avec le C m'a convaincu que je pourrai toujours faire face à ce genre de problème s'il se présentait. C'est surtout un problème d'anticipation pour éviter, après des mois de développement, de se retouver comme un con à foutre un projet en l'air à cause ça.

C'est vrai qu'un des avantages de Python, c'est sa bonne entente avec d'autres langages. Par exemple, je l'utilise avec Delphi (qui me permet de me créer mes interfaces graphiques).

Sur ce, bon apprentissage de Python :D
06/08/2005, 18h24
Guigui_

Citation:

Envoyé par miminum

Oups, j'avais pas bien regardé :

Tu as changé 1 / (float (i+1) ) par 1.0 / (i+1).

Autant pour moi.

C'est ça (j'ai quand même vérifier qu'on obtenait le même résultat :wink: )
Il fallait que l'un des 2 termes soient un float pour que le calcul se fasse sur des floats (ca, c'est un truc pénible quand on manipule des termes dont on ne sait pas si ce sont des int ou des floats, ca force parfois à caster un peu tout dans tous les sens et donc à y perdre en performance).