Discussion :

[Jiyuu]

Bonjour à tous,

Il y a quelques jours, dans le cadre d’une reprise à zéro d’un projet écrit en PyQt, je me suis posé la question suivante :
Quel choix pour coder et déployer son programme : Qt en C++ ou Python ?

Les arguments donnés pour le C++ sont principalement basés sur les performances de celui-ci, mais dans mon cas cette caractéristique n’est pas forcément primordiale surtout que Python a des performances plus que correctes (faut pas un veau non plus ). Au pire la piste de Cython peut être envisagée.

Mais ce sondage, mon expérience et la lecture du topic de Mokochan ainsi que la réponse de Tyrtamos, me pousse à me poser la question suivante :
Quand le cas se présente, vaut-il mieux choisir les outils originels de Python ou préférer ceux du binding utilisé ?

Qu’en pensez-vous ? N’hésitez pas à argumenter et éventuellement à donner des exemples.
Vous pouvez aussi réagir sur mon premier sondage, celui-ci est toujours ouvert.

Un grand merci à Mokochan et Tyrtamos qui m’ont permis d’illustrer cette question avec leurs messages, m’évitant ainsi de trouver et écrire un bout de code .

++

J

[mokochan]

Un grand merci à Mokochan et Tyrtamos qui m’ont permis d’illustrer cette question avec leurs messages, m’évitant ainsi de trouver et écrire un bout de code .

Pas de quoi!

Je me suis mise au python et au Qt il y a peu de temps, j'aurais donc du mal à donné un avis très argumenté (Tyrtamos fera sans doute mieux que moi à ce niveau-là ).

Personnellement j'aime bien utiliser quand j'en ai l'occasion, les outils du binding Qt. Quitte à utiliser ce binding, autant se servir le plus possible des possibilités qu'il offre!
En tout cas, s'il s'agit d'un aspect "IHM", je préfère utiliser une solution Qt qui sera vraiment dédiée au traitement de mon problème, typiquement comme pour le cas que je décris dans le post cité par Jiyuu: la fonction "partial" peut être utilisée pour lier un même slot à plusieurs signaux tout en pouvant différencier le widget émetteur, mais QSignalMapper est fait exprès pour ça.

De plus, on ne sait jamais, si un jour on me demande par exemple de retranscrire mon programme en C++/Qt, j'aurais moins de mal à le faire si j'ai privilégié les outils Qt aux outils python.
Par contre c'est vrai que ce n'est pas si simple de connaître toutes les possibilités de Qt, par exemple j'ignorais l'existence de la classe QSignalMapper ou encore QValidator (format du contenu d'un champ de saisie) au départ (j'avais donc commencé par utiliser des solutions python), et suis tombée dessus un peu par hasard. Même si la documentation de Qt est très complète, il faut savoir que cela existe! ^^

Après je pense qu'un programme peut être codé très proprement et très bien fonctionner avec les outils python qui permettent de faire à peu près tout! Tout dépend du contexte.

[Jiyuu]

De plus, on ne sait jamais, si un jour on me demande par exemple de retranscrire mon programme en C++/Qt, j'aurais moins de mal à le faire si j'ai privilégié les outils Qt aux outils python.

C'est effectivement une raison très bonne. La retranscription en C++ n'en sera que facilité.

Par contre c'est vrai que ce n'est pas si simple de connaître toutes les possibilités de Qt, par exemple j'ignorais l'existence de la classe QSignalMapper ou encore QValidator (format du contenu d'un champ de saisie) au départ (j'avais donc commencé par utiliser des solutions python), et suis tombée dessus un peu par hasard. Même si la documentation de Qt est très complète, il faut savoir que cela existe!

En fait le problème de Qt et donc en ce qui nous concerne de PyQt, c'est surtout qu'on peut tout faire avec, mais parfois il faut 2 ou 3 lignes de plus (voire plus).

Un exemple flagrant est celui de la lecture d'un fichier texte par exemple.

Cependant la cohésion du code est, me semble-t-il, réellement primordial et ça fait toujours moins d'import

[Invité]

Je pense qu'il faut s'adapter à la situation. Si tu es dans un contexte Qt, mieux vaut utiliser les outils Qt, sinon, les outils python.

Par exemple, mettons que j'ai besoin d'un thread pour un traitement au niveau de la base de données. Si j'utilise Qt pour accéder à ladite base, je vais avoir tendance à utiliser QThread. Par contre, si j'ai choisi d'utiliser SQLAlchemy avec le connecteur sqlite3 embarqué dans python, j'aurais alors tendance à utiliser les threads python.

[Jiyuu]

Je pense qu'il faut s'adapter à la situation. Si tu es dans un contexte Qt, mieux vaut utiliser les outils Qt, sinon, les outils python.

Par exemple, mettons que j'ai besoin d'un thread pour un traitement au niveau de la base de données. Si j'utilise Qt pour accéder à ladite base, je vais avoir tendance à utiliser QThread. Par contre, si j'ai choisi d'utiliser SQLAlchemy avec le connecteur sqlite3 embarqué dans python, j'aurais alors tendance à utiliser les threads python.

Je suis entièrement d'accord avec toi, mais ... (il y a toujours un mais ), à l'origine, si tu fais un programme en PyQt, pourquoi partir avec SQLAlchemy alors que tu as tous les outils intégrés dans binding de Qt ?

[Invité]

Pour sa puissance
Je n'ai pas utilisé personnellement le module database de Qt, mais d'après les échos que j'en ai eu, il ne rivalise pas avec une ORM tel que SQLAlchemy.

Après, tout dépend bien sur du besoin.

Il peut aussi s'agir d'une technologie imposée.

[tyrtamos]

Bonjour,

En réfléchissant un peu à la question posée, je m'aperçois que j'applique dans mes choix un critère assez précis: La proximité plus ou moins grande avec le graphique. Si ça touche le graphique de près: je choisis les outils PyQt4. Sinon, je choisis les outils Python.

Ainsi:

- comme je l'ai dit, je préfère QThread à threading à cause de ses capacités d'échange de messages avec la fenêtre graphique.

- je préfère ftplib plutôt que QFtp, Parce que la seule liaison avec le graphique est dans l'éventuelle barre de progression. Pour tout le reste, ftplib fonctionne très bien, et j'apprécie de pouvoir envoyer des requêtes de bas niveau avec.

- pour utiliser sqlite3, je préfère QtSql quand il s'agit de consulter/modifier la table d'une base de données relationnelle (QTableView), mais je reviens au pilote Python sqlite3 pour tous les autres cas quand je n'utilise pas le graphique! Ceci dans le même programme mais, bien sûr, il n'y a jamais de connexion ouverte avec les 2 pilotes en même temps. Je trouve que le pilote Python est mieux défini, que les mécanismes des transactions et la gestion des erreurs sont plus claires, et toujours plus en avance au niveau version.

- pour lire et écrire un fichier, je préfère les outils Python plutôt que QFile.

- ayant des documents pdf à fabriquer, j'ai pensé utiliser reportlab, mais je suis revenu rapidement à QPrinter qui fait ça très bien et qui, de plus, continuera à fonctionner sous Python 3.x.

- pour manipuler des images, je préfère les outils PyQt plutôt que PIL (pourtant puissant).

- pour le multimédia, y compris pour jouer des sons (fichier wav, mp3), je préfère les outils PyQt, même si l'arrivée de PyQt5 va me perturber (phonon n'existe plus).

-etc...

En gros, je considère PyQt comme une "simple" bibliothèque graphique, et j'utilise ses outils dès qu'il y a une relation avec du graphique, et les modules Python sinon. J'ai donc voté: "ça dépend..." et j'ai donné ici mon critère.