Discussion :

[Jiyuu]

Bonjour,

Apr�s plusieurs mois sans programmation je reviens parmi vous avec notamment le projet de reprendre l'un de mes programmes depuis le d�but.

L'id�e est surtout d'am�liorer le programme cot� � programmeur � (cot� utilisateur il sera aussi �toff�, mais ceci n'est pas le but de cette discussion), le but �tant de d�obtenir un code :
� plus simple ;
� plus lisible ;
� plus facilement maintenable ;
� plus facilement mettable � jour.

Afin d�obtenir le meilleur compromis, je me pose alors les deux questions suivantes :
� pour la partie codage, mieux vaut-il faire un code en � pureQt � (en C++) ou utiliser l�un de ses binding (principalement en Python) ?
� pour le d�ploiement, faut-il favoriser la cr�ation d�un ex�cutable ou diffuser le code source et les biblioth�ques n�cessaires ?

Ces questions ne sont pas forc�ment tr�s simples de r�ponse car supposent que les deux langages soient connus � niveau �quivalent. Malgr� tout une approche peut �tre faite pour d�grossir le sujet.

N�h�sitez pas apporter en plus de vos votes un argumentaire en s�parant bien les deux questions, m�me si elles peuvent �tre �troitement li�es, il est peut-�tre plus simple de d�ployer d�une certaine mani�re avec un certain choix de langage�

Au niveau du code, il faut aussi remarquer que Qt Creator, l'EDI d�velopp� sp�cialement pour Qt, ajoute le support de Python dans sa derni�re pr�version.

Merci pour votre contribution.

J

[arnolddumas]

Afin d�obtenir le meilleur compromis, je me pose alors les deux questions suivantes :
� pour la partie codage, mieux vaut-il faire un code en � pureQt � (en C++) ou utiliser l�un de ses binding (principalement en Python) ?

Je n'ai pas une grande exp�rience en Python donc mon avis sera forc�ment biais� mais j'ai vot� pour du code 100% C++. Je ne sais pas si l'application que tu d�veloppes est gourmande mais les performances seront bien meilleurs en C++ qu'en Python. Ca d�pend aussi de ton exp�rience avec ces deux langages. Il y en a forc�ment un des deux que tu maitrises mieux que l'autre.

� pour le d�ploiement, faut-il favoriser la cr�ation d�un ex�cutable ou diffuser le code source et les biblioth�ques n�cessaires ?

Je dirais que �a d�pend des syt�mes d'exploitation vis�s. Pour Windows et Mac, il faut imp�rativement faire un installeur. Pour Linux, BSD et autres, le mieux est de mettre les sources sur Github ou �quivalent. Apr�s, un simple git clone suivi d'un cmake ou d'un qmake et le logiciel tourne sur la machine.

Si le logiciel est un minimum int�ressant, il se retrouvera packag� dans la plupart des distributions. Tu peux aussi maintenir toi-m�me les paquets.

[dourouc05]

les performances seront bien meilleurs en C++ qu'en Python

Il faut encore voir si l'augmentation de perfs est si ph�nom�nale que �a� et aussi si �a a la moindre importance dans le cas pr�cis. Je ne pense pas que l'aspect performances brutes doit �tre le premier crit�re pour le choix. (D'ailleurs, Python n'a g�n�ralement pas � rougir de ses performances, bien que ce n'est pas son but principal.)

[Apocalyps]

Bonjour � tous, pour ce sondage, j'ai r�pondu :

Sans h�siter, un code 100 % en Qt ;

Tout simplement C++ (car Python n'est pas encore � mon ordre du jour ), l'interface de Qt Creator est amplement suffisante pour mes projets.

La cr�ation d'un ex�cutable sera plus propice � am�liorer le "SAV" ;

ainsi que

La distribution des sources et des biblios sera d'une grande efficacit�.

Ayant le projet de faciliter l'utilisation de mes logiciels pour les utilisateurs lambda, je me doit de cr�er un installeur Windows (minimum).
Les sources sont n�anmoins disponible dans le cadre du logiciel libre et du portage Linux.

[jbb2811]

Le probl�me de performance est relatif.
Certes dans l'absolu le C++ est plus performant que le python, mais:
1) suivant ce que fait ton application �a se verra pas forcement ( � moins que tu fasse du traitement d'image/video ... ), et de toute fa�on python ou C++ la lib Qt et donc l'IHM restera en natif
2) comme c'est plus rapide/facile de coder en python qu'en C++, il te reste plus de temps pour optimiser

[azias]

Utiliser python n�cessiterait que tes utilisateurs installent un interpr�teur python. Et distribuer les sources plut�t qu'un ex�cutables n�cessitent que tes utilisateurs installent la cha�ne de compilation et fassent la compilation eux-m�mes.

Donc si tes utilisateurs ne sont pas tr�s avertis, il vaut mieux d�velopper en C++ et d�ployer un ex�cutable avec toutes les biblioth�ques dynamiques n�cessaires (dans un zip ou mieux via un installateur). Evidemment il faudra compiler pour diverses architectures si tu veux que ce soit multiplateformes.

S'il est plus facile ou plus pratique pour toi de d�velopper en python, il y a peut �tre moyen de faire un installateur qui installera l'interpr�teur python automatiquement?

�a ne t'emp�che pas de distribu�s les sources � part si tu veux faire de l'open source.

[grim7reaper]

Utiliser python n�cessiterait que tes utilisateurs installent un interpr�teur python.

Pas n�cessairement.
Il est possible de convertir un script en fichier .exe qui embarque son interpr�teur et toutes les biblioth�ques n�cessaires avec lui.
cx_freeze est un outil qui permet �a (et qui a le bon go�t d��tre compatible Python 3)

[Jiyuu]

Je tiens d�j� � tous vous remercier pour vos votes et/ou commentaires.

Je souhaite r�agir sur trois points :

La performance du langage :
� mon sens il existe au moins trois niveaux de performance pour un langage :

• La performance li�e � la rapidit� d'�crire le code ;
• La performance li�e � la vitesse d'ex�cution, de consommation de ressources, ... ;
• La performance li�e � sa maintenabilit� dans le sens large du terme (maj, correction bogues, ...) ;

Comme Dourouc et jbb2811 le sugg�re, je pense que la performance li�e � la vitesse de calcul, etc est tr�s relative. Je pense que vous aurez compris que je suis avant tout un codeur Python. J'avoue n'avoir jamais vraiment �t� g�n� de ce cot�. Les seules fois o� j'ai eu l'impression de ralentissement �tait bien souvent au moment d'ex�cuter des requ�tes Sql sur un serveur distant, et l� je pense que les performances de Python ne sont pas forc�ment les seules en cause.

D'autre part, bien que je n'ai pas une tr�s grande exp�rience en C++, j'ai lu ici et l� que ce n'�tait pas la panac�e en simplicit� de codage, ma faible exp�rience me fait dire aussi ceci et jbb semble aussi sugg�rer. Python est, je pense, plus performant de ce cot�.

La distribution du code :
Pour le C++, j'utilise depuis longtemps un logiciel �crit dans ce langage et dont les premi�res versions �taient exclusivement distribu�es en version source. M�me �tant sous windows, je n'ai jamais rencontr� de difficult� pour l'utiliser. Je pense que tout peut tr�s bien se passer si c'est bien pr�par�.

Pour Python, je pense qu'il faut distinguer les applications destin�es � tourner sur Win ou sur Linux comme l�indique arnolddumas.
Pour Linux, cela risque d'�tre beaucoup moins probl�matique puisque Python est pr�sent de base (et C++ aussi au passage ^^), il ne reste plus qu'� g�rer les biblioth�ques manquantes.
Pour Win, j'avoue l� �tre un peu plus dans le flou car tous les programmes que j'ai fait actuellement ont soit �t� exclusivement pour moi (donc j'ai d�j� mon Python), soit distribu� via un ex�cutable, et je confirme que cela peut tr�s bien se passer.

Cependant, il existe des solutions dites portables de Python qui peuvent avantageusement �tre distribu�es avec les sources du programme. Je me demande m�me dans quelle mesure, un simple copier-coller du dossier Python et quelques r�glages ne permettraient pas de r�gler le probl�me (test en cours )

Quid de la taille du programme ?
Le probl�me peut venir de l�.
En Python et pour des petits � moyens projets on va rapidement atteindre les 350 ou 400Mo� certes �a peut paraitre peu vu les 1 000Go bien souvent disponibles, mais bon...
J�ai aussi derni�rement essay� de cr�er un ex�cutable d�un programme exemple fourni avec Qt5.0.2. Si j�ai bien compris, une fois le .exe cr��, il est n�cessaire d�y ajouter quelques DLL. J�ai �t� assez surpris de la taille de Qt5Guid.DLL et d�autres� et me dit que finalement, un programme source python distribu� avec tout ce qui faut pour le faire tourner n�a pas forc�ment � rougir.

En esp�rant que ces quelques remarques permettrons encore d�alimenter le d�bat, et peut-�tre de faire r�agir des pro-Python

Merci � vous pour votre implication.

[arnolddumas]

D'autre part, bien que je n'ai pas une tr�s grande exp�rience en C++, j'ai lu ici et l� que ce n'�tait pas la panac�e en simplicit� de codage, ma faible exp�rience me fait dire aussi ceci et jbb semble aussi sugg�rer. Python est, je pense, plus performant de ce cot�.

C'est vrai que le C++ a vraiment des c�t� si0ux parfois.

Pour le C++, j'utilise depuis longtemps un logiciel �crit dans ce langage et dont les premi�res versions �taient exclusivement distribu�es en version source. M�me �tant sous windows, je n'ai jamais rencontr� de difficult� pour l'utiliser. Je pense que tout peut tr�s bien se passer si c'est bien pr�par�.

D'un autre c�t�, tu es d�veloppeur. 99% des gens ignore ce qu'est un compileur ou m�me un langage de programmation donc il ne faudrait pas g�neraliser. Tant mieux si tu arrives � compiler un logiciel mais je doute que ce soit le cas des utilisateurs finaux, sauf si le logiciel en question s'addresse aux d�veloppeurs.

Le probl�me peut venir de l�.
En Python et pour des petits � moyens projets on va rapidement atteindre les 350 ou 400Mo� certes �a peut paraitre peu vu les 1 000Go bien souvent disponibles, mais bon...
J�ai aussi derni�rement essay� de cr�er un ex�cutable d�un programme exemple fourni avec Qt5.0.2. Si j�ai bien compris, une fois le .exe cr��, il est n�cessaire d�y ajouter quelques DLL. J�ai �t� assez surpris de la taille de Qt5Guid.DLL et d�autres� et me dit que finalement, un programme source python distribu� avec tout ce qui faut pour le faire tourner n�a pas forc�ment � rougir.

Oui mais c'est Qt5Guid.dll aussi. N'oublies pas que c'est la version debug, avec plein de symboles inutiles (pour la distribution) dedans. Les version release sont nettement plus l�g�res.

Pour que le programme prenne 300 Mo avec les dlls release, il faut utiliser quasiment tous les modules de Qt.

[Jiyuu]

D'un autre c�t�, tu es d�veloppeur.

C'est gentil, mais je ne me consid�re que comme un d�veloppeur � plusquamateur �

99% des gens ignore ce qu'est un compileur ou m�me un langage de programmation donc il ne faudrait pas g�neraliser. Tant mieux si tu arrives � compiler un logiciel mais je doute que ce soit le cas des utilisateurs finaux, sauf si le logiciel en question s'addresse aux d�veloppeurs.

Ta remarque a attir� plus que mon attention. Je me suis peut-�tre un peu emball�...
Huuuummm.... comment dire... il est possible que j'ai pris, dans ma m�moire d�faillante (message pour Dourouc : c'�tait pas que de la Belge ), la version ReadyToUse (non setup�e) pour une version source

Oui mais c'est Qt5Guid.dll aussi. N'oublies pas que c'est la version debug, avec plein de symboles inutiles (pour la distribution) dedans. Les version release sont nettement plus l�g�res.

Alors l� tu me rassures et tu d�montres � merveille que j'ai des lacunes en C++

Pour que le programme prenne 300 Mo avec les dlls release, il faut utiliser quasiment tous les modules de Qt.

C'est exactement �a. De m�moire :

• Python jsute apr�s son installation : 50 � 60 Mo ;
• Python apr�s l'installation de PyQt : 250 � 300Mo.

J'ai mis la main sur une version portable de Python, pratique mais 250Mo, avec une possibilit� de r�duire car il y a toutes les biblioth�ques.

[Jiyuu]

Bon, derni�re (ou pas) tentative de faire venir des Pythoniens
Mani�re simple de faire une version portable de Python, c'est de choisir une installation pour un utilisateur unique lors de l'installation de Python...

Allez les gars, faut faire tourner la balance dans l'autre sens

[grim7reaper]

Franchement, il n�y a pas vraiment mati�re � h�siter.

Si tu connais bien Python et que ton application est pas gourmande en calcul, bah go Python.
Le code sera plus court, plus lisible, plus maintenable, et plus portable (pas besoin de distribuer X ex�cutables).

Et puis m�me si c�est gourmand, il y a peu de chances que �a soit l�interface qui calcule. Donc au pire tu fais le c�ur qui calcul avec un truc qui d�pote (numpy, pypy, C++, �) et tu restes sur du Python pour l�interface.


[avis perso]
Moi je n�ai jamais vraiment aim� Qt � cause de l��tape interm�diaire avec le pr�processeur pour g�n�rer du code � partir des macros que tu dois foutre partout dans ton code. Je trouve �a moche au possible�
Cela dit, j�ai pas franchement d�alternative � proposer donc �a reste un ressenti personnel, pas sp�cialement une critique technique (�a ne r�duit en rien la qualit� de Qt).
Il y a aussi la propension que Qt a (avait ? Para�t que �a change un peu maintenant) � faire doublon avec la biblioth�que standard sur certains point (bon, �a c�est compr�hensible vu qu�� l��poque des premi�res versions de Qt, la biblioth�que standard c��tait pas aussi bien foutu que maintenant).

Par contre, quand j�ai test� Qt avec Python, l� c��tait beaucoup plus � joli �, plus naturel (vu que Python de base offre d�j� des m�canismes d�introspection) du coup j�ai pris plaisir � coder avec ce couple.
[/avis perso]

[Invit�]

Il y a trois choses qui me d�rangent avec PySide/PyQt :

• Le style : les bindings ne respectent pas la pep8, et quand on utilise d'autres modules qui la respectent, on aboutit � un code h�t�rog�ne sur le plan du style.
• Le support des IDE : je n'arrive pas � obtenir une auto compl�tion correcte sur ces bindings. J'utilise PyCharm, et impossible de g�n�rer les squelettes python. Ce serait cool que QtCreator propose un bon support de Python. J'ai h�te de voir ce que �a va donner sur la version 2.8 finale.
• Le fait que certains modules Qt sont redondants avec la librairie standard (threading, networking...). Une bonne pratique consiste � utiliser les modules Qt lorsque l'on interagit avec un contexte Qt, et les modules de la librairie standard sinon. Il n'en reste pas moins qu'on va potentiellement avoir l'utilisation de plusieurs modules diff�rents pour le m�me usage final.

Mais en dehors de �a, PySide/PyQt reste pour moi une des solutions id�ales pour du GUI cross-platform.

Le probl�me que j'ai avec le d�veloppement C++ pour des applications qui n'ont pas besoin de perfs extraordinaires, c'est que j'ai l'impression que la plus grande partie de ma concentration est verrouill�e sur la gestion m�moire pour pas faire de conneries.
La productivit� est d�multipli�e en Python et pour 99% des applications perso que je vais faire, je n'ai pas besoin de la rapidit� apport�e par le C++. Au pire, l'int�gration de code natif est assez ais�.

[HS]
Il y a aussi JavaFx2 qui semble assez int�ressant dans ce domaine. Il permet aussi de faire du packaging d'applications pour avoir des apps "self-contained".
Sans oublier aussi le trio JS/HTML/CSS qui commence � arriver sur desktop.
[/HS]

[Jiyuu]

Le support des IDE : je n'arrive pas � obtenir une auto compl�tion correcte sur ces bindings. J'utilise PyCharm, et impossible de g�n�rer les squelettes python. Ce serait cool que QtCreator propose un bon support de Python. J'ai h�te de voir ce que �a va donner sur la version 2.8 finale.

Je t'invite � lire ce tutoriel
Pour la version 2.8 de QtCreator, je ne pense pas que �a aille bien au del� de ce qu'il y a � pr�sent. Au pire la possibilit� de faire un F5 .
En tout cas je ne pense pas que l'on atteindra le niveau de performance et d'efficience que l'on peut avoir avec le couple QtDesigner-Eric.

Je ne connais pas PyCharm. Cela semble �tre un IDE de plus, mais � priori orient� Django, l'un des plus c�l�bres framework web de Python. Il n'est peut-�tre pas forc�ment le plus d�di� pour cod� du PyQt ou PySide.

Le fait que certains modules Qt sont redondants avec la librairie standard (threading, networking...). Une bonne pratique consiste � utiliser les modules Qt lorsque l'on interagit avec un contexte Qt, et les modules de la librairie standard sinon. Il n'en reste pas moins qu'on va potentiellement avoir l'utilisation de plusieurs modules diff�rents pour le m�me usage final.

On ne peut qu'�tre d'accord avec toi su ce point. Le gros souci est que parfois on se casse la t�te � essayer de faire un truc en Qt alors que Python le permet tr�s simplement (le formatage de nombre par exemple).

[Shuty]

Python sort des temps tr�s satisfaisant. Certe il restera toujours derri�re le c++ mais ca reste une alternative interressante.

Dans mon cas, je dirais bien sure : 100% cpp