| Les deux révisions précédentesRévision précédente | |
| itc:tps:tp1:exercice2 [2021/10/22 23:32] – ↷ Page déplacée de nsi:tds:serveur_web20:itc:tps:tp1:exercice2 à itc:tps:tp1:exercice2 goupillwiki | itc:tps:tp1:exercice2 [2021/10/22 23:37] (Version actuelle) – ↷ Liens modifiés en raison d'un déplacement. goupillwiki |
|---|
| Un dernier mot sur le ''in'', intégré à Python. Notre fonction ''est_element'' fait exactement la même chose et bien sûr. Maintenant que nous avons passé du temps à l'écrire, est-il indifférent d'utiliser ''a in L'' plutôt que ''est_element(L, a)'' ? | Un dernier mot sur le ''in'', intégré à Python. Notre fonction ''est_element'' fait exactement la même chose et bien sûr. Maintenant que nous avons passé du temps à l'écrire, est-il indifférent d'utiliser ''a in L'' plutôt que ''est_element(L, a)'' ? |
| |
| Eh bien non, ''a in L'' sera **beaucoup plus rapide**. La qualité de notre programmation n'est pas en cause. ''in'' utilise le même mécanisme. Mais Python est un langage peu performant en termes de vitesse d'exécution. On l'aime car il est facile à programmer, pas pour sa vitesse. Quand on a besoin de vitesse et d'efficacité, on peut se tourner vers des langages plus difficiles comme le [[nsi:tds:serveur_web20:langages:c:start|C]]. | Eh bien non, ''a in L'' sera **beaucoup plus rapide**. La qualité de notre programmation n'est pas en cause. ''in'' utilise le même mécanisme. Mais Python est un langage peu performant en termes de vitesse d'exécution. On l'aime car il est facile à programmer, pas pour sa vitesse. Quand on a besoin de vitesse et d'efficacité, on peut se tourner vers des langages plus difficiles comme le [[nsi:langages:c:start|C]]. |
| |
| Alors pourquoi ''in'' va plus vite que notre ''est_element'' ? n'est-il pas en Python lui aussi ? Pas tout à fait. Les commandes de Python font appel à du code écrit en C, donc plus rapide. De ce fait, une fonction intégrée sera toujours plus rapide que son équivalent écrit en pur Python. | Alors pourquoi ''in'' va plus vite que notre ''est_element'' ? n'est-il pas en Python lui aussi ? Pas tout à fait. Les commandes de Python font appel à du code écrit en C, donc plus rapide. De ce fait, une fonction intégrée sera toujours plus rapide que son équivalent écrit en pur Python. |
| |
| C'est d'ailleurs une force de Python : prenons l'exemple des //data-scientists// qui analysent d'énormes bases de données et utilisent Python. Pourquoi le font-ils alors que Python est lent ? En vérité ils utilisent surtout Python comme programme principal, très facile et rapide à écrire, et qui lance des commandes trouvées dans des bibliothèques toutes faites -- on trouve des bibliothèques toutes faites pour énormément de choses en Python, comme [[https://scikit-learn.org/stable/|scikit-learn]], [[https://pandas.pydata.org/|pandas]], [[https://numpy.org/|numpy]], [[https://www.sympy.org/en/index.html|sympy]], ... -- qui utilisent par exemple le C et sont donc très rapides. Ainsi a-t-on le meilleur des deux mondes : Simplicité de programmation de Python, efficacité de C.</WRAP> | C'est d'ailleurs une force de Python : prenons l'exemple des //data-scientists// qui analysent d'énormes bases de données et utilisent Python. Pourquoi le font-ils alors que Python est lent ? En vérité ils utilisent surtout Python comme programme principal, très facile et rapide à écrire, et qui lance des commandes trouvées dans des bibliothèques toutes faites -- on trouve des bibliothèques toutes faites pour énormément de choses en Python, comme [[https://scikit-learn.org/stable/|scikit-learn]], [[https://pandas.pydata.org/|pandas]], [[https://numpy.org/|numpy]], [[https://www.sympy.org/en/index.html|sympy]], ... -- qui utilisent par exemple le C et sont donc très rapides. Ainsi a-t-on le meilleur des deux mondes : Simplicité de programmation de Python, efficacité de C.</WRAP> |
