Discussion :

[jiggyOne]

Hey,
J'apprends à programmer en python depuis peu avec le livre Apprendre Python 3 de Gérard Swimmen et je trouve que c'est un bon langage.
Mais je vois souvent ou même de la bouche de certaines personnes Python n'est pas performant et efficace par rapport aux autres langages (compilés,...) pour des applications ou logiciels à installer sur un bureau.
J'aimerais savoir si c'est fondé ou pas ?
Devrais je voir vers autre langage pour les applications pour bureau ?

[tyrtamos]

Bonjour,

Ceux qui disent que Python n'est pas performant sont surtout ceux qui ne connaissent pas bien le langage. De même que lorsqu'on dit que Python n'est qu'un langage de script alors qu'on peut faire avec des programmes complexes (graphiques, multimédias, gestion de base de données, réseau, etc...).

En fait si la partie purement interprétée est déjà assez performante, Python donne la main rapidement à des modules écrits en C ou C++ qui s'exécutent en langage machine. C'est le cas pour le calcul scientifique, les bibliothèques graphiques, etc... ainsi que les modules personnels qu'on a trouvé pertinent de traduire en C ou C++.

Une fois le programme Python au point, on peut le transformer en exécutable indépendant (avec pyinstaller, cx_freeze, ...) qui pourra être exécuté sur des PC qui n'ont pas Python installé (ou pas avec la bonne version). On peut même utiliser un "installeur" comme innosetup sous Windows, ou fabriquer un "paquet" sous Linux, et un utilisateur pourra installer le programme sur son PC sans savoir que c'est du Python!

Un petit exemple de programme Python multimédia avec la bibliothèque graphique PyQt5 qui permet de jouer des radios internet sur son PC: http://python.jpvweb.com/python/mesr...pyqt5_radioweb.

En ayant la facilité et la rapidité de développement de la partie interprétée, et la partie rapide des modules écrits en C ou C++, on a ainsi le "meilleur des deux mondes".

Bien sûr, des applications critiques de type temps réel nécessiteront probablement un autre langage plus adapté.

[wiztricks]

Salut,

J'aimerais savoir si c'est fondé ou pas ?

Sûr que c'est fondé: un langage interprété sera toujours plus lent qu'un langage compilé (moderne).

Mais dans la réalité, dès que vous allez programmer sérieusement vous allez utiliser Python pour "commander" des bibliothèques graphiques ou numériques écrites dans des langages comme C/C++ et qui seront, elles, compilées.

Côté performances, la différence sera négligeable pour autant que vous sachiez déléguer le gros du boulot à ces bibliothèques là. Sinon, rien ne vous empêche de compiler un sous ensemble de vos scripts Python grâce à des bibliothèques comme Cython.

Et s'il y a plein de solutions, cela ne doit pas vous faire négliger l'apprentissage d'autres langages que Python... mais attendez d'avoir un peu appris à programmer pour çà.

- W

[jiggyOne]

quels sont les limites de python et des langages interprètes en général ?

[wiztricks]

quels sont les limites de python et des langages interprètes en général ?

Vous pourrez difficilement faire de la programmation système (mais certains langages compilés ne le peuvent pas non plus)... et la principale limite sera essentiellement (et pour un certain temps puisque vous débutez) dans vos compétences à faire avec.

- W

[Bktero]

Python n'est pas performant et efficace par rapport aux autres langages (compilés,...)

Il faut aussi voir ce qu'on attend d'un programme en terme de performances.

Si tu veux faire de l'acquisition vidéo en temps réel, traiter le flux vidéo pour faire de la détection faciale, et afficher la vidéo avec des carrés autour des têtes, il faut effectivement un programme qui ne perd pas de temps pour limiter au maximum le décalage entre la réalité et la vidéo affichées par ton programme.

Si tu veux faire une interface pour afficher les données météo de ta ville, tu t'en fiches sur le programme soit plus lent parce que tu utilises un langage interprété plutôt que compilé. Tu as la latence des requêtes sur un site web pour avoir les informations, les inconnues sur les performances sur le réseau. Alors si toutes les heures quand tu mets à jour ton affichage des données météo, ça met 10 secondes au lieu de 1, quelle différence ?

[lg_53]

J'appuie le propos de Bktero : Performant c'est un mot à relativiser. Selon 2 critères principaux : la taille des données que tu dois manipuler ET le temps de réponse maximale toléré (temps réel ou non, délai, etc ...)

[jmbain]

La question est aussi passionnante que récurente.
Il est admis communément qu'un langage interprêté est plus lent qu'un langage compilé.
Mais dans la pratique, on constate souvent que l'interpréteur ne fait pas grand chose de plus lourd qu'un code généré par un compilateur. Il traduit le code, certes, mais c'est instantané.
Si l'on examine le byte code résultant, on constate qu'il s'agit surtout de manipulations de pile et de branchements dans le coeur du système.
Si l'on reste sur des instructions basiques, et que l'on programme sans utiliser la puissance du langage, d'accord, c'est plus lent, de beaucoup.
Par contre, si l'on utilise des instructions "puissantes", qui font beaucoup de travail en elle-même, alors la puissance du langage est fonction de son efficacité interne, qui est tout simplement celle d'un langage compilé.
Rappelons que python est programmé en C. Je postule que dans bien des cas, un code python est plus rapide qu'un code équivalent en C.
Essayez de faire une boucle en C qui fera la même chose qu'une liste en compréhension (une base de python), ce n'est pas certain que vous aurez un résultat plus rapide.
Jetez un coup d'oeil sur le code source de python, vous verrez que c'est extrêmement bien optimisé.

Je bavarde, mais pratiquons, ce sera plus parlant.

Le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
import dis
def tst():
	for x in range(100):
		if int(x/2) == x/2:
			print(x,end=' ')
tst()
dis.dis(tst)

dont voici le résultat :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 58 60 62 64 66 68 70 72 74 76 78 80 82 84 86 88 90 92 94 96 98   4           0 SETUP_LOOP              48 (to 50)
              2 LOAD_GLOBAL              0 (range)
              4 LOAD_CONST               1 (100)
              6 CALL_FUNCTION            1
              8 GET_ITER
        >>   10 FOR_ITER                36 (to 48)
             12 STORE_FAST               0 (x)
 
  5          14 LOAD_GLOBAL              1 (int)
             16 LOAD_FAST                0 (x)
             18 LOAD_CONST               2 (2)
             20 BINARY_TRUE_DIVIDE
             22 CALL_FUNCTION            1
             24 LOAD_FAST                0 (x)
             26 LOAD_CONST               2 (2)
             28 BINARY_TRUE_DIVIDE
             30 COMPARE_OP               2 (==)
             32 POP_JUMP_IF_FALSE       10
 
  6          34 LOAD_GLOBAL              2 (print)
             36 LOAD_FAST                0 (x)
             38 LOAD_CONST               3 (' ')
             40 LOAD_CONST               4 (('end',))
             42 CALL_FUNCTION_KW         2
             44 POP_TOP
             46 JUMP_ABSOLUTE           10
        >>   48 POP_BLOCK
        >>   50 LOAD_CONST               0 (None)
             52 RETURN_VALUE

Le ligne 26 "46 JUMP_ABSOLUTE" nous laisse supposer un branchement, et donc un code assez lent, car une bonne partie de ces instructions vont être exécutées autant de fois que d'itérations dans la boucle. C'est normal, ce code python est à peine digne d'un débutant.

Par contre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
def tst():
	print([x for x in range(100) if int(x/2) == x/2])

qui donne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
[0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 64, 66, 68, 70, 72, 74, 76, 78, 80, 82, 84, 86, 88, 90, 92, 94, 96, 98]
 11           0 LOAD_GLOBAL              0 (print)
              2 LOAD_CONST               1 (<code object <listcomp> at 0x7f3762f7f8a0, file "lst.py", line 11>)
              4 LOAD_CONST               2 ('tst2.<locals>.<listcomp>')
              6 MAKE_FUNCTION            0
              8 LOAD_GLOBAL              1 (range)
             10 LOAD_CONST               3 (100)
             12 CALL_FUNCTION            1
             14 GET_ITER
             16 CALL_FUNCTION            1
             18 CALL_FUNCTION            1
             20 POP_TOP
             22 LOAD_CONST               0 (None)
             24 RETURN_VALUE

et semble montrer l'absence de tout branchement.
J'en déduis que la liste en compréhension est gérée de façon optimum, en une fois, d'une façon qui serait peut-être difficile à faire aussi bien en C, car programmée une fois pour toute.

Je suis tenté de conclure que la puissance du langage fait loi, et non pas son caractère compilé/interprêté, qui me paraît une opposition obsolète depuis bien longtemps déjà. En fait, ce genre de discussion avait lieu à propos de java dans les années 90 ; ceci ne nous rajeunit pas...

Et sans donner dans le côté partisan, python est tellement fourni en modules ultra-puissants, que pour finir, je ne vois guère de langage aussi performant d'un point de vue global.

[jmbain]

Bof, après un test rapide, ce que je raconte n'est pas vérifié.
Je n'en reviens pas.

[Sve@r]

Bonjour

Je bavarde, mais pratiquons, ce sera plus parlant.

J'adore ce genre de fraicheur dans un discours

print([x for x in range(100) if int(x/2) == x/2])

Je pense que si on veut faire un test de perfs, on partira quand-même d'un code plausible. A mon avis, aucun habitué de Python écrira if int(x/2) == x/2 quand il peut écrire if x//2 == x/2 ou même if x%2 == 0...

Bof, après un test rapide, ce que je raconte n'est pas vérifié.
Je n'en reviens pas.

Il n'y a rien de plus frustrant que d'avoir une théorie qui s'appuie sur un raisonnement correct et qui, donc, ne peut que se voir vérifiée... et qui ne l'est au final pas
Malheureusement je pense que ton test a dû être compromis par certaines optimisations internes.

J'aimerais savoir si c'est fondé ou pas ?

Je me souviens de mon premier projet en Python. Un truc pas vraiment difficile en soi mais qui effectuait énormément de calculs. J'ai donc abordé, en bon débutant de ce langage, le projet sous forme classique (des tableaux, des boucles, des calculs).
Au final, ça fonctionnait mais avec des données réelles (grosso-modo 60000 lignes de 8 colonnes) le bouzin mettait plus de 5mn pour donner un résultat.

Ensuite avec l'expérience j'y suis revenu. En tentant des solutions diverses encore et encore. A la fin, je suis passé par sqlite pour avoir la puissance du requêtage SQL (parce qu'il me fallait parfois éliminer certaines lignes selon le choix de l'utilisateur donc je pouvais, en SQL, mettre mes lignes en table puis ne récupérer que celles dont la colonne X était à True) et le truc est descendu à 30 secondes. Et je n'ai pas tenté numpy que je ne connais pas mais d'après les echo, peut-être que je pourrais gagner encore (mais bon, le projet est fini donc...)

Tout ça pour dire que oui, Python pur ok c'est lent. Mais Python + tout ce qui a été fait à côté et qu'on peut relier via un simple import sera quasiment aussi rapide qu'un compilé. Toutefois tout dépend au final de ce qu'on veut/peut mettre dans ce "quasiment"...
Perso j'aime bien cette page et surtout cette conclusion "Il y a des tas de raisons de ne pas choisir Python bien entendu, mais probablement la meilleure raison de le choisir, c’est qu’il y a peu de chance de se planter."

Devrais je voir vers autre langage pour les applications pour bureau ?

Avant de réfléchir à ce qui ne peut pas se faire en Python, je te conseillerais peut-être d'abord t'intéresser à ce qui a été fait en Python...

[jiggyOne]

merci c'était bien illustrer.Mais c'était quoi le projet ?

[viper1094]

Je bavarde, mais pratiquons, ce sera plus parlant.

J'adore ce genre de fraicheur dans un discours

Hahaha elle est joli celle là.

[VinsS]

A mon avis, aucun habitué de Python écrira if int(x/2) == x/2 quand il peut écrire if x//2 == x/2 ou même if x%2 == 0...

Bien sur que non, aucun dev python ne fait de choses comme cela.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
Python 3.6.8 (default, Jan 14 2019, 11:02:34) [GCC 8.0.1 20180414 (experimental) [trunk revision 259383]] on linux
>>> import dis
>>> dis.dis("int(i/2) == i/2")
  1           0 LOAD_NAME                0 (int)
              2 LOAD_NAME                1 (i)
              4 LOAD_CONST               0 (2)
              6 BINARY_TRUE_DIVIDE
              8 CALL_FUNCTION            1
             10 LOAD_NAME                1 (i)
             12 LOAD_CONST               0 (2)
             14 BINARY_TRUE_DIVIDE
             16 COMPARE_OP               2 (==)
             18 RETURN_VALUE
>>> dis.dis("not i & 1")
  1           0 LOAD_NAME                0 (i)
              2 LOAD_CONST               0 (1)
              4 BINARY_AND
              6 UNARY_NOT
              8 RETURN_VALUE

CQFD

[jiggyOne]

aussi est-il important d'utiliser une machine virtuelle?

[Sve@r]

Sacré VinsS. J'avais pas pensé à "&"
Ou peut-être que j'ai écrit un code que je voulais inconsciemment adaptable à tout diviseur

merci c'était bien illustrer.Mais c'était quoi le projet ?

Analyse de signal

aussi est-il important d'utiliser une machine virtuelle?

Qu'entends-tu par "important" ? Ca dépend de ton besoin.
Moi par exemple je code sous Linux mais faut que mes trucs fonctionnent sous W7/W10 donc oui j'utilise des machines virtuelles pour tester avant de déployer.
Bref la virtualisation te permet de tester dans différents environnements mais ce n'est pas obligatoire pour simplement coder...

[Pyramidev]

Rappelons que python est programmé en C. Je postule que dans bien des cas, un code python est plus rapide qu'un code équivalent en C.

Plus rapide ?! Faut pas déconner non plus.

Par contre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
def tst():
	print([x for x in range(100) if int(x/2) == x/2])

qui donne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
[0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 64, 66, 68, 70, 72, 74, 76, 78, 80, 82, 84, 86, 88, 90, 92, 94, 96, 98]
 11           0 LOAD_GLOBAL              0 (print)
              2 LOAD_CONST               1 (<code object <listcomp> at 0x7f3762f7f8a0, file "lst.py", line 11>)
              4 LOAD_CONST               2 ('tst2.<locals>.<listcomp>')
              6 MAKE_FUNCTION            0
              8 LOAD_GLOBAL              1 (range)
             10 LOAD_CONST               3 (100)
             12 CALL_FUNCTION            1
             14 GET_ITER
             16 CALL_FUNCTION            1
             18 CALL_FUNCTION            1
             20 POP_TOP
             22 LOAD_CONST               0 (None)
             24 RETURN_VALUE

et semble montrer l'absence de tout branchement.
J'en déduis que la liste en compréhension est gérée de façon optimum, en une fois, d'une façon qui serait peut-être difficile à faire aussi bien en C, car programmée une fois pour toute.

Bof, après un test rapide, ce que je raconte n'est pas vérifié.
Je n'en reviens pas.

Il n'y a rien de plus frustrant que d'avoir une théorie qui s'appuie sur un raisonnement correct et qui, donc, ne peut que se voir vérifiée... et qui ne l'est au final pas

Je crois que vous n'avez pas compris ce bytecode.

Voici comment j'interprète ce bytecode :

• La première instruction CALL_FUNCTION appelle range(100).
• La deuxième instruction CALL_FUNCTION appelle une sous-fonction de la forme :
  

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  def the_subfunction(result_of_range_100):
     return [x for x in result_of_range_100 if int(x/2) == x/2]

  sur le résultat de range(100). the_subfunction est la sous-fonction qui avait été construite et déposée dans la pile par les 3 instructions :
  

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
                2 LOAD_CONST               1 (<code object <listcomp> at 0x7f3762f7f8a0, file "lst.py", line 11>)
                4 LOAD_CONST               2 ('tst2.<locals>.<listcomp>')
                6 MAKE_FUNCTION            0

• La troisième instruction CALL_FUNCTION appelle print sur le résultat précédent.

Des branchements, il y en a à deux endroits :

• Il y en a plusieurs dans la fonction que j'ai appelé the_subfunction. Quand j'ai testé dis.dis(tst), j'ai eu deux code successifs : celui qui correspond à la fonction tst puis celui qui correspond à la sous-fonction que j'ai appelée the_subfunction :
  

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  26
  27
  28
  29
  30
  31
  32
  33
  34
  35
  >>> dis.dis(tst)
    2           0 LOAD_GLOBAL              0 (print)
                2 LOAD_CONST               1 (<code object <listcomp> at 0x000002B7132F4810, file "<stdin>", line 2>)
                4 LOAD_CONST               2 ('tst.<locals>.<listcomp>')
                6 MAKE_FUNCTION            0
                8 LOAD_GLOBAL              1 (range)
               10 LOAD_CONST               3 (100)
               12 CALL_FUNCTION            1
               14 GET_ITER
               16 CALL_FUNCTION            1
               18 CALL_FUNCTION            1
               20 POP_TOP
               22 LOAD_CONST               0 (None)
               24 RETURN_VALUE
   
  Disassembly of <code object <listcomp> at 0x000002B7132F4810, file "<stdin>", line 2>:
    2           0 BUILD_LIST               0
                2 LOAD_FAST                0 (.0)
          >>    4 FOR_ITER                28 (to 34)
                6 STORE_FAST               1 (x)
                8 LOAD_GLOBAL              0 (int)
               10 LOAD_FAST                1 (x)
               12 LOAD_CONST               0 (2)
               14 BINARY_TRUE_DIVIDE
               16 CALL_FUNCTION            1
               18 LOAD_FAST                1 (x)
               20 LOAD_CONST               0 (2)
               22 BINARY_TRUE_DIVIDE
               24 COMPARE_OP               2 (==)
               26 POP_JUMP_IF_FALSE        4
               28 LOAD_FAST                1 (x)
               30 LIST_APPEND              2
               32 JUMP_ABSOLUTE            4
          >>   34 RETURN_VALUE
  >>>

  Dans ce bytecode, POP_JUMP_IF_FALSE correspond au saut du if int(x/2) == x/2. FOR_ITER gère le saut pour sortir de la boucle et JUMP_ABSOLUTE correspond au saut pour revenir au début de la boucle.
• Il y a forcément des branchements dans l'appel de print sur la liste retournée par the_subfunction, car il y a forcément une boucle sur les éléments.

[jiggyOne]

Pour un blog, par exemple je voudrais utiliser un framework de Python soit Django soit Flask .Ou devrais opter pour du php pour me simplifier la tâche ?

[wiztricks]

Salut,

Ou devrais opter pour du php pour me simplifier la tâche ?

Si vous maîtrisez déjà PHP, sûr que réaliser un projet codé avec PHP sera plus simple: la réponse à cette question dépend de ce que vous connaissez et avec quels langages frameworks vous vous sentez le plus à l'aise.

Et si vous voulez réaliser un blog qui sorte un peu du lot (des blogs gratuits, c'est pas ce qui manque, vous pouvez même en créer sur developpez.com), il faudra maîtriser aussi HTML, CSS, JavaScript, protocoles réseaux, bases de données,...
qui sont des domaines qui sont difficile à aborder sans savoir un minimum programmer.

Si vous apprenez à programmer (accessoirement avec Python, car pour apprendre à programmer, il faut pratiquer et donc utiliser un langage de programmation) vos questions pourraient avoir du sens si devant les difficultés, la lenteur, les frustrations d'un apprentissage, vous vous demandiez s'il n'y a pas de solutions plus simple/rapide.

Plus simple et plus rapide serait de demander de faire le boulot à un programmeur... i.e. quelqu'un qui a eu la patience d'apprendre et la chance de réaliser quelques projets significatifs proches de celui que vous voulez.

Et si la seule chose qui vous intéresse est le résultat final, et qu'il sera plus à l'aise pour le coder en Java, C++ ou Ruby qu'est ce qui ferait souhaiter à ce que ce soit plutôt codé avec PHP ou avec Python?
Est-ce que çà va apporter des fonctionnalités supplémentaires à l'utilisateur final?
Est-ce que ce sera plus facile à maintenir parce que vous avez plus de compétences dans ces langages là?

Tout çà sont des questions "non techniques": çà n'apporte rien à l'utilisateur final mais se rapportent à un contexte spécifique à chaque projet et qui n'a rien à voir avec les langages de programmation retenus.

- W