Quel framework GUI utilisez-vous pour vos programmes Python en 2013 ?

Quel framework utilisez-vous pour les interfaces graphiques de vos programmes Python en 2013 ?
Quelles sont les raisons qui ont motivé ce choix ?

Bonjour,

Le développeur Python, amateur ou non, a un choix important en ce qui concerne la bibliothèque graphique lors de la conception de ses programmes.

Pour des raisons d’habitude, de plateforme, de licence, d'esthétiques ou toute autre raison son choix va alors se tourner vers un framework GUI bien précis.

Et vous ?

:fleche: Avec quel framework GUI travaillez-vous actuellement ? Pour quelle(s) raison(s) ?
:fleche: Seriez-vous prêt ou envisageriez-vous de changer ? Si oui, pour lequel ? Et pourquoi ?
:fleche: Ou bien êtes-vous de ceux qui pensent que Python, c'est bien mais pas pour des GUI. Quels sont vos griefs ? Que manque-t-il à Python ?

Participez au débat et n'hésitez pas à argumenter votre vote en confrontant votre point de vue avec les autres membres et en donnant les raisons de votre choix, vos expériences passées, vos remarques... N'hésitez pas à discuter l'évolution depuis notre précédent sondage.

Bon vote à tous

On peut faire des interfaces graphiques en Python ? :aie:

bonjour,
J'ai choisi wxpython pour le nombre de ses widgets et leur esthétisme .
Point noir il n'y a pas de version pour python 3 dommage .

Citation:

---

Envoyé par olaxius

bonjour,
J'ai choisi wxpython pour le nombre de ses widgets et leur esthétisme .
Point noir il n'y a pas de version pour python 3 dommage .

---

Une bonne raison peut-être de passer à PyQt ou PySide :whistle: (comment ça je ne suis pas impartial ? :mouarf:)

Bonjour,

J'utilise wxPython 2.8.12. Il y a vraiment beaucoup de sortes de widgets.
Le widget wx.grid est très souple pour représenter les données sous forme de grille.
Le module d'impression est correct (seul petit bug gênant : quand je demande 2 copies, j'en reçois 4).

Je ne connais pas PyQt / PySide. De toute manière, ça me prendrait beaucoup trop de temps pour transformer mes programmes.

Pour info, une version wxPython 2.9.5 pour Python 3.2 et 3.3 est en cours de développement (http://www.wxpython.org/Phoenix/snapshot-builds/). Elle me semble déjà fonctionnelle pour une utilisation simple. Je ne l'utilise pas car l'outil wx.grid me semble buggé (gridCellRenderer, gridCellEditor, déplacement des colonnes, ...).

Bonjour :)

J'utilise Tkinter il est simple et en natif sous python. Les petits moins, les widgets sont moins nombreux que dans les autres bibliothèques et Tkinter n'est pas super thread safe même si Tcl/tk est compilé avec l'option enable threads.

Bonjour à tous,

Personnellement, j'utilise PYGTK. Bien qu'un peu brut de décoffrage, au niveau esthétique, il est relativement aisé de le prendre en main, et les widgets présents sont suffisants pour la plupart des usages. De plus, travaillant sous environnement GTK, cela semble plus naturel.

Si je désire ne pas embêter l'utilisateur avec des librairies externes, j'utilise tkinter. Mais j'avoue ne pas etre fan du style "bloc de beton" :mouarf:

Concernant le changement, je n'en ressent pas le besoin. Mais sinon, j'hésiterai je pense entre wx et qt, pour leur côté esthétique. J'y viendrai probablement un jour mais ce sera avant tout par curiosité. Peut être après par conviction.

J'ai un peu utilisé PyQt pour un projet professionnel, et couplé avec QtDesigner ça reste une bonne solution si correctement installé (j'utilise la distribution WinPython qui est relativement bien équipé).
http://code.google.com/p/winpython/

Par contre j'ai récemment découvert Kivy et sa gestion du "multi-touch" et je pense l'utiliser pour un futur projet.
http://kivy.org/

Sans grande surprise j'ai voté pour PyQt / PySide.

Pourquoi ?
Avant tout, il faut savoir que je suis passé par Tkinter (:aie:) puis wxPython avant d'arriver à PyQt / PySide. Je connais donc ces deux frameworks, même si cela fait un bail que je ne les ai plus utilisés.

Le gros avantage avec PyQt / PySide réside notamment dans le fait qu'ils sont extrêmement complets et très régulièrement mis à jour, en particulier PyQt qui suit de très prêt à la fois l'évolution de Python et celle de Qt (la dernière version de PyQt est compatible avec Python 3.3 et est basée sur Qt 5.1)

Avec ces framework il n'y a quasiment rien que l'on ne puisse faire, ce qui m'avait même pousser à me poser la question : si j'ai le choix, vaut-il mieux utiliser les outils originels de Python ou plutôt préférer ceux du framework ?

Leur utilisation est aussi très aisée et la documentation très complète. Il est en outre assez simple de trouver de l'aide avec la doc Qt ou la FAQ Qt si jamais il manque des infos en "pur" PyQt / PySide.

Et pour finir, l'esthétique est vraiment très bien faite.

Que du positif quoi :mouarf:

Salut,

Je ferais la même réponse qu'il y a 3 ans: il n'y a toujours pas de GUI Python qui s'impose au delà de bindings qui permettent aux programmeurs d'utiliser Tk, Qt, Wx, ... a partir de Python.

Ce qui conduit a plusieurs défauts:

• Pour les utiliser efficacement, le programmeur devra traduire une documentation et des exemples écrits pour un programmeur C, C++, TCL,... C'est bien pour la gymnastique des neurones, mais arriver a traduire sans perte n'est pas gagne.
• Les différences dans la gestion mémoire ne sont pas toujours maîtrisables (Python utilise un GC, les frameworks autre chose). Ce qui rend délicat la maintenance de telles applications (au delà du brico, proto, truc fait sur un coin de table).
• Certains frameworks sont "intrusifs": Qt par exemple apporte beaucoup de fonctionnalités que Python a déjà. Faut-il utiliser le paradigme Qt (et pourquoi programmer en Python dans ce cas) ou programmer en Python sauf pour la partie GUI?(*)
• Comme ce sont des "bindings", il est aussi complique de les utiliser en natif qu'en Python (nombre de lignes). La facilite de leur mise en œuvre avec Python est sympa pour débuter, mais pourra devenir contre-productive au delà.

Pas de soucis tant qu'on reste dans le brico, proto,... On utilise souvent dans ce cas, les fonctionnalités "basiques" , illustrées dans les tutos, et (relativement) faciles a mettre en œuvre quelque soit le framework.

Ceci dit Wx, Tk, Qt, Gtk,.... sont des frameworks de GUI de l'informatique client/serveur du siècle dernier. Plein d'applications ont ete construites avec et il est bon de savoir comment ça fonctionne pour se depatouiller avec.

Les IHM d'aujourd'hui sont plutôt HTML5, JavaScript, CSS et Kivy (déjà cite) ou panda3d sont un peu moins "has been".

- W

Citation:

---

Envoyé par wiztricks

Les IHM d'aujourd'hui sont plutôt HTML5, JavaScript, CSS et Kivy (déjà cite) ou panda3d sont un peu moins "has been".

---

Et QML disponible avec PyQt5 :mouarf:.

Citation:

---

Envoyé par Jiyuu

Et QML disponible avec PyQt5 :mouarf:.

---

QML est une interface déclarative.
Si on veut faire du HTML5, ça passe par du Webkit et GoogleV8 qui sont intégrés a Qt mais aussi disponibles "ailleurs".
Ca permet de rafraîchir le framework. Et c'est une bonne chose pour prolonger la vie des applications existantes.
Mais les nouvelles applications ont une structure différente.


- W

Bonjour,

Oui, bon. Quand on voit les entreprises qui travaillent encore avec Windows XP, on se dit que les outils du siècle dernier ont encore de belles années devant eux...

En ce qui me concerne, j'utilise PyQt4 depuis 4 ans.

J'ai commencé avec tkinter, et je ne le regrette pas. Et puis, il me fallait trouver une bibliothèque graphique plus musclée pour un projet important. En particulier, il me fallait un logiciel de dessin de fenêtre pour créer des fenêtres complexes pour la saisie, et une possibilité de consulter et modifier une base de données relationnelle avec une grille type Excel. Tout cela en multiplateforme Windows-Linux-MacOSX.

J'ai regardé wxPython, PyGtk et PyQt4. J'ai éliminé wxPython parce qu'à ce moment-là, il n'y avait aucun projet pour passer à Python 3. Et entre PyGtk et PyQt4, j'ai choisi PyQt4 parce que le logiciel de dessin de fenêtre QtDesigner me plaisait beaucoup.

Je n'ai pas eu à regretter mon choix: avec PyQt4, on peut faire vraiment tout ce qu'on veut, et plus encore: on découvre en permanence des possibilités qu'on ne connaissait pas.

Avec PyQt4, j'ai fait des choses comme:

- saisie de données avec fenêtres complexes
- consultation/modification de bases de données relationnelles avec une grille. Possibilité de tri, filtrage, recherche, y compris recherche avec jokers, expressions régulières ou mot similaire. On peut afficher en interactif n'importe quel résultat de requête SQL de type select sous forme d'une grille, avec possibilité d'enregistrement en csv pour transmission à un tableur (on peut aussi transférer des données par copier-coller ou par glisser-déposer).
- création de pdf
- intégration d'un navigateur web. Je l'utilise pour afficher les manuels de mes logiciels que j'écris en html, mais on peut aussi naviguer sur le web (y compris avec javascript, flash, etc...)
- intégration d'un éditeur de texte
- création et lecture de code-barre.
- échange de données en réseau local hétérogène (surtout Windows-Linux)
- traitement multimedia: manipulation d'images et émission de fichiers audio
- création de nouveaux widgets avec intégration dans QtDesigner
- sauvegarde et restauration des données en ftp (avec barre de progression) sous forme de fichier zip
- navigation web
- émission/réception d'emails, en texte simple ou en html, avec ou sans pièces jointes
- conversion en programme "standalone" avec cx_freeze (.exe sous Windows: avec un installeur comme innosetup, l'utilisateur ne sait même pas que c'est du Python).
- etc...

Avec ça, j'ai fait un logiciel pour un concours international de photos pour mon photo-club: il fait maintenant plus de 25000 lignes. Je l'utilise depuis 3 ans et il fonctionne parfaitement.

Avec PyQt4, j'ai fait d'autres logiciels comme un programme de recherche de mots dans les fichiers d'une arborescence ou un programme d'émission d'emails en masse (plusieurs centaines) avec ou sans pièces jointes, en texte simple ou en html, pour les mailing de mon photo-club (logiciel que je ne diffuse pas, parce qu'on peut faire du spam avec...).

Ayant découvert (grâce à ce forum!) qu'on pouvait mettre un logiciel en "tray" (à droite dans la barre des tâches), j'ai créé une fenêtre PyQt4 qui encapsule l'interpréteur Python comme le fait idle avec tkinter, et qui charge plusieurs modules de calcul perso. A l'allumage de mon PC, j'ai une icône qui vient dans la zone de notification. Quand je clique dessus, la fenêtre PyQt4-Python s'affiche, et je peux faire tous les calculs que je veux (y compris une simulation de crédit bancaire par exemple). Je peux aussi appeler un éditeur de texte pour écrire une note de type "postit", ou pour me rappeler ce que j'ai écris la dernière fois. Etc... Et quand je ferme cette fenêtre, en fait elle est cachée et se réaffiche à l'identique la fois suivante: c'est vraiment très pratique.

J'ai plein d'autres projets. Par exemple, j'aimerais faire un processeur d'idée avec un affichage arborescent (QTreeWidget). Je pense aussi à un tableur (QTableWidget) qui fonctionnerait avec des scripts Python, ainsi qu'à un logiciel de sauvegarde incrémentielle. Etc...

Ce que je regrette? Que la doc de PyQt4 soit en C++ et en anglais. Avec une bibliothèque aussi complète et aussi complexe, on travaille en permanence avec la doc à l'écran.

En fait, il est surtout dommage que les dirigeants de Python n'aient pas choisi d'intégrer une bibliothèque graphique puissante comme PyQt4 (ou PyGtk!) comme module "normal" de Python plutôt que tkinter qui nécessite un "autre" interpréteur (tcl/tk): ça fait un peu bricolage. Il est aussi dommage qu'un logiciel comme cx_freeze ne soit pas intégré aussi. Avec en plus un outil de développement de type "RAD" comme pour Delphi, cela donnerait un sacré coup d'accélérateur à Python, et lui ferait perdre définitivement son image de "simple langage de script".

A part ça, j'aimerais aussi, en plus et pas à la place, programmer en Python pour les machines avec écran tactile (PC, tablettes, smartphones), avec fonction "multi-touch". Je creuse actuellement la solution "kivy" pour voir.

Bonjour à tous, j'utilise WxPython 2.9.3 parce que l'interface graphique, sur un mac en tout cas, c'est nettement plus joli que tkinter (presque pur Mac). Il y a quelques bugs encore mais globalement cela fonctionne nickel pour moi (avec python 2.7.3). Je n'ai pas essayé les autres gui pour des raisons de temps (apprendre une interface est assez long et fastidieux au début).

Salut Tyrtamos,

Citation:

---

Envoyé par tyrtamos

Oui, bon. Quand on voit les entreprises qui travaillent encore avec Windows XP, on se dit que les outils du siècle dernier ont encore de belles années devant eux...

---

Programmer, c'est "construire" de nouveaux outils ou faire évoluer des "outils" existants. Il est rare de changer de GUI ou de SGBD pour une évolution et encore plus rare de changer de langage de programmation. C'est un peu moins contraint pour les nouvelles applications. Un des intérêt de Python est de permettre d'explorer de nouveaux paradigmes i.e. la construction de nouveaux outils.

Citation:

---

Avec ça, j'ai fait un logiciel pour un concours international de photos pour mon photo-club: il fait maintenant plus de 25000 lignes. Je l'utilise depuis 3 ans et il fonctionne parfaitement.

---

Python et Qt sont "scalables", pas de soucis.
Mettre 25000 lignes de codes en production/maintenance d'un tel mix. n'est pas facile a vendre (en entreprise).
Cherchez un programmeur Qt, il devra connaître Qt et le développement C++. Connaître PyQt et Python sera un "plus" mais insuffisant pour le job.

Si on sort du cadre professionnel, on ne parle plus d'applications mais de "brico", "proto",... et de ses passions. Elles sont respectables mais difficile de généraliser, ...

Citation:

---

Ce que je regrette? Que la doc de PyQt4 soit en C++ et en anglais. Avec une bibliothèque aussi complète et aussi complexe, on travaille en permanence avec la doc à l'écran.

---

C'est un des défauts que j'ai mentionne.
Revoyez la discussion. Faire marcher un truc est une chose, le construire proprement en est une autre.

Citation:

---

En fait, il est surtout dommage que les dirigeants de Python n'aient pas choisi d'intégrer une bibliothèque graphique puissante comme PyQt4 (ou PyGtk!) comme module "normal" de Python plutôt que tkinter qui nécessite un "autre" interpréteur (tcl/tk): ça fait un peu bricolage.

---

Toutes les fonctionnalités intégrées a la "Python Standard Library" doivent répondre a des contraintes de compatibilité ascendante qui rendent difficiles leurs évolutions.

Tkinter est la depuis longtemps, imho, il faudrait pouvoir s'en défaire (installe optionnellement) plutôt que d'essayer de le remplacer (ajouter un autre truc dans la PSL).
C'est un peu comme pour sqlite, 'battery-included', c'est bien... mais c'est aussi un "soft" installable et utilisable en mode "console". Ce qui vient avec Python sera toujours décale et cause de "soucis".

Citation:

---

Avec en plus un outil de développement de type "RAD" comme pour Delphi, cela donnerait un sacré coup d'accélérateur à Python, et lui ferait perdre définitivement son image de "simple langage de script".

---

"Python" est a la fois un langage de programmation mais vient avec nombre de fonctionnalités prêtes a l'emploi, la PSL qui en fait aussi une sorte de "framework", boite a outils bien pratique.

Qt est aussi un "framework" mais comme on peut l'utiliser depuis Python, C++, Java,... Il y a moins de "confusion" entre "langage de programmation" et "framework".

Si vous voulez construire une boite a outils avec les fonctionnalités DELPHI on pourrait commencer par y ajouter SQLAlchemy, Camelot,...

La plupart des composants existent en open-source.
Et vous avez des éditeurs comme ActiveState ou autres (Embarcadero) qui proposent des solutions qui intègrent composants Open Source et des composants propriétaires modulo finance.

Il faut bien rémunérer le travail de sélection, intégration, documentation, et les coûts de structure cote non-régression, montée de version, support,...
D'ailleurs DELPHI n'est ni gratuit, ni open source et encore moins un langage de programmation.

- W

Bonjour wiztricks,

Citation:

---

Si on sort du cadre professionnel, on ne parle plus d'applications mais de "brico", "proto",... et de ses passions. Elles sont respectables mais difficile de généraliser, ...

---

Vous êtes trop binaire: on vend, et c'est du professionnel, ou on ne vend pas et c'est du bricolage. Dans le domaine associatif, quand on fait un logiciel pour un concours international, il DOIT remplir ses fonctions sans bug. Ce n'est pas parce qu'on ne le vend pas qu'il ne doit pas être construit selon les règles de l'art, et avec tous les contrôles nécessaires (j'ai les qualifications pour ça). Et c'est le cas! Par ailleurs, dans le passé, j'ai déjà vendu des programmes (en Pascal), et ça s'est très bien passé. En résumé, ce n'est pas parce que je prends du plaisir à coder que je ne code pas sérieusement...

Citation:

---

Revoyez la discussion. Faire marcher un truc est une chose, le construire proprement en est une autre.

---

Je n'ai pas vu le rapport avec ma remarque (doc C++ et anglais)

Citation:

---

Toutes les fonctionnalités intégrées a la "Python Standard Library" doivent répondre a des contraintes de compatibilité ascendante qui rendent difficiles leurs évolutions.

---

Et oui, sauf pour Python 3 qui a un peu "cassé" cette compatibilité ascendante: on aurait pu en profiter, mais on ne l'a pas fait: c'est bien dommage.

Citation:

---

D'ailleurs DELPHI n'est ni gratuit, ni open source et encore moins un langage de programmation.

---

Ça, pour ne pas être gratuit, il n'est pas gratuit: j'ai reçu une proposition de mise à jour pour ... 2000€. Waou.

Borland avait utilisé le nom de Delphi parce qu'il avait modifié assez profondément le Pascal standard (POO, graphique, etc...). Delphi représente donc en même temps ce Pascal modifié et son outil de développement "RAD" (=avec le dessin interactif des fenêtres).

Il reste que Lazarus + Freepascal (http://www.lazarus.freepascal.org/) s'en approche assez bien. De plus, il existe aussi sous Linux et MacOSX, contrairement à Delphi. Enfin, il est gratuit: c'est donc possible!!! Pourquoi pas un Python à la sauce Lazarus qui intègre PyQt et QtDesigner?

Citation:

---

Envoyé par wiztricks

Python et Qt sont "scalables", pas de soucis.
Mettre 25000 lignes de codes en production/maintenance d'un tel mix. n'est pas facile a vendre (en entreprise)

---

J'aimerai juste revenir sur cette remarque pour laquelle je suis tout à fait d'accord... sauf qu'avec PyQt (ou PySide) on a la possibilité de TOUT faire.

Une installation PyQt fonctionnelle permet de faire des choses simples comme la création d'une petite interface graphique à des choses plus complexe comme travailler avec de l'XML, imprimer des PDF, manipuler des fichiers audio, vidéo ou photo; tracer des courbes ... sans aucun rajout de bibliothèque.

En fait, si un jour Riverbank (PyQt) ou Digia (PySide) venait à avoir l'idée "d'imbriquer" la bonne version de Python dans leur exe d'installation je suis sûr que le développeur n'aurait qu'un seul programme à installer pour coder ses projets..., mais bon là il faut en installer 2 : Python et le binding voulu.

Pour revenir à ta remarque, oui mixer deux langages dans 25 000 lignes c'est dangeureux, sauf que là on pourrait en fait considérer ceci comme un seul et unique langage.
À titre de comparaison (même si l'utilisation originelle n'est pas censée être la même), on est bien loin de PHP+HTML+JS... là oui merci la maintenance.

Salut Tyrtamos,

Citation:

---

Envoyé par tyrtamos

Vous êtes trop binaire: on vend, et c'est du professionnel, ou on ne vend pas et c'est du bricolage.

---

Pas du tout!
Il y a des différences entre un soft ecrit sur un coin de table et une application open source ou propriétaire dont architecture, code et livrables devront être présentés, discutés, documentes, développes et maintenus par d'autres que soi.

Citation:

---

Dans le domaine associatif, quand on fait un logiciel pour un concours international, il DOIT remplir ses fonctions sans bug. Ce n'est pas parce qu'on ne le vend pas qu'il ne doit pas être construit selon les règles de l'art, et avec tous les contrôles nécessaires (j'ai les qualifications pour ça).

---

Tout logiciel mérite d’être "bien construit". Les méthodes existent, les moyens ne sont pas toujours a la hauteur.
Parmi ces moyens, faire "contrôler", et "faire revoir" son code par d'autres est (insuffisant mais) nécessaire pour garantir un minimum de qualité.
Cela ne veut pas dire que votre code n'est pas bien construit juste que vous confondez "confiance" et "qualifications" avec "contrôle" et qualité"...

- W

Re:

Citation:

---

Envoyé par tyrtamos

Et oui, sauf pour Python 3 qui a un peu "cassé" cette compatibilité ascendante: on aurait pu en profiter, mais on ne l'a pas fait: c'est bien dommage.

---

C'est parce qu'on casse qu'on doit bumper la version
Si ce n'avait pas été le cas, on aurait fait un Python 2.8.
- W

@wiztricks

J'arrête de discuter ici. J'ai donné mon avis, et il n'a pas changé. Le reste ne m'intéresse pas.

Bonjour,

Citation:

---

Avec quel framework GUI travaillez-vous actuellement ? Pour quelle(s) raison(s) ?

---

Actuellement, avec PyQt, mais j'utilise pour de simples petits dialogues Homme Machine, assez aisément Tkinter.

Tkinter pour sa simplicité, et juste pour faire le travail d'interface graphique simple.

PyQt pour son côté plus complet concernant la GUI et l'esthétique.

Citation:

---

Seriez-vous prêt ou envisageriez-vous de changer ? Si oui, pour lequel ? Et pourquoi ?

---

Non, tout simplement parce-que ces deux IHM se complètent bien et me suffisent.

Maintenant si je dois adapter une IHM spécifique pour un projet, alors je le ferais, il est évident que se sera long et fastidieux.

Citation:

---

Ou bien êtes-vous de ceux qui pensent que Python, c'est bien mais pas pour des GUI. Quels sont vos griefs ? Que manque-t-il à Python ?

---

J'en suis pas loin, je travaille sous Unix et j'ai l'habitude de travailler avec le Terminal, ça ne m'embête pas d'exécuter mes codes en brut sans IHM.

Il faut vraiment que j'en sois obligé, et souvent se sont pour des codes partagés et utilisés par d'autres.

Citation:

---

Envoyé par wiztricks

Mettre 25000 lignes de codes en production/maintenance d'un tel mix. n'est pas facile a vendre (en entreprise).
Cherchez un programmeur Qt, il devra connaître Qt et le développement C++. Connaître PyQt et Python sera un "plus" mais insuffisant pour le job.

---

Je ne suis pas d'accord...

Utiliser python en entreprise n'a rien de gênant, d'ailleurs si on l'utilise côté production, c'est aussi pour le gain de temps de codage.

Utiliser le C/C++ aura un intérêt si on a besoin de performance pure niveau calculatoire.

D'ailleurs si on utilise PyQt ou Qt sans parler d'autres choses que d'interface, quelle est la différence?

Pour cela il est nettement plus simple de faire de l'interfaçage de langages en python et C++, python pour l' IHM et C++ pour les calculs.

Citation:

---

Envoyé par wiztricks

le construire proprement

---

Ça veut dire quoi proprement pour vous ? Respecter la PEP8 ? Autres ?

Deux codeurs professionnels diront que pour leur code faisant la même chose, chacun des codes adverses ne sera pas propre, qui a raison?

Les codes respectant la PEP8, les consignes de la documentation officielle, et maintenables, sont des codes propres, non?

Bonjour,

Concernant le PyQt et le C++, je ne voudrais pas que des lecteurs pensent qu'il est nécessaire de savoir développer en C++ pour utiliser PyQt: ce serait complètement faux.

Comme la doc est en C++ comme je l'ai dit, il faut simplement comprendre les déclarations en C++ pour les convertir en Python. En particulier, on ne code rien en C++, on n'utilise pas le compilateur ni l'éditeur des liens, etc... Un petit peu de pratique et on fait ça facilement.

Mais, comme je l'ai dit, ce serait encore mieux si la doc était en Python (et en français, mais là, je rève :D)

Pour tout ce qui touche au cadre professionnel, merci de continuer le débat sur le fil http://www.developpez.net/forums/d13...l/#post7460635

PyQt pour ma part

pour son look, sa doc, toutes les fonctionnalités qu'il apporte sans aller chercher le module qu'il faut (thread, sql, impression, ...)

Je bosse dans un service info pour une société d'import/logistique/douane/transport.
L' ERP de l'entreprise est fait maison avec un langage plus du tout utilisé mais taillé sur mesure. J'ai été engagé pour maintenir/évoluer le truc :aie:
Dans peu d'années on changera ou réécrira le truc.

On utilise pour les autres développements windev, python en complément.

J'ai réalisé quelques projets utilisés en interne en PyQt (impression/mailing pdf, gestion des heures du personnel, etiquettes code barres EAN 128).
Il est clair qu'on est pas une structure info telle que l'a définie wiztricks mais PyQt est utilisable en entreprise.
On a de même déployé en externe notre soft compta avec quelques fonctionnalités PyQt (artisan, commercants, bureau comptable, ..)

Citation:

---

Envoyé par wiztricks

D'ailleurs DELPHI n'est ni gratuit, ni open source et encore moins un langage de programmation.

---

Petite précision : Dire que Delphi n'est pas un langage de programmation est un comble. Delphi est un EDI mais basé sur le langage Pascal Objet qui est aussi appelé Delphi ...

Et en ce qui concerne l'intégration des bases de données, la très confortable construction d'IHM, la vitesse d'exécution (entre autres) et maintenant les applications mobiles, Python est encore loin derrière. Ce n'est pas pour rien si Delphi a eu du succès et que de nombreux logiciels professionnels ont été développés avec. D'ailleurs, sa carrière commerciale semble redémarrer. Pour info, l'éducation nationale sud-africaine retient Delphi à la place de Java pour l'enseignement de la programmation. C'est vrai,elle aurait pu regarder Python aussi, mais bon.

Pour le côté Open Source, il y a Lazarus mais il est moins complet même si, pour un outil gratuit, c'est sacrément bluffant.

Cela dit, j'apprécie beaucoup Python car on développe très vite avec, la syntaxe est vraiment très cool, sans fioriture et sans doute un peu plus moderne que le Pascal, fût-il objet.

Enfin je suis bien embêté pour choisir un framework pour mes petits développements Python...

Citation:

---

Envoyé par e-ric

Petite Précision : Dire que Delphi n'est pas un langage de programmation est un comble. Delphi est un EDI et par extension le langage Pascal Objet disponible est aussi appelé Delphi ...

---

Tout a fait, DELPHI un "framework" pour développer des applications 4GL. Et s'il a été (et est encore) utilise, c'est pour tout ce qu'on peut faire cote RAD. Si ce n’était que le langage "Pascal Objet", ca aurait eu moins de succes.
Une analogie (osee) pourrait être SAP (le logiciel ERP) et ABAP.
- W

Alors là, ça sent (est-ce le mot ?) le préjugé et peut-être un manque d'information... Que penses-tu ne pas pouvoir faire avec un outil comme Delphi ? Argumentes un peu.

est-ce que Python a eu tant de succès que cela ?? remarques que Python est sorti bien avant Delphi. Framework ... un mot à la mode, sur Delphi, on parle de bibliothèques, ça fait moins hi-tech mais ça marche au moins.

InnoSetup, mentionné plus bas, est écrit en Delphi.

Une application de 25000 lignes ne fait pas peur dans le monde Delphi.
Je viens de regarder des extraits de QML, ça ressemble beaucoup au contenu des fichiers dfm de Delphi sauf que dans Delphi, ça fait un paquet d'années qu'on les a.

Aucune comparaison possible avec SAP et ABAP, Delphi est un outil de développement généraliste.

Pour moi, Delphi (ou Lazarus) et Python sont des outils complémentaires, je les utilise pour des applications différentes

Ce que je veux dire c'est que DELPHI est un IDE *et* un langage de programmation. Si on peut presque tout faire avec un langage de programmation, le succès du framework vient surtout de la facilite d'utilisation apportée par l'IDE.
Et c'est par pour rien que Microsoft et d'autres s'en sont beaucoup inspires.
Suis je plus clair?
- W

Ouais

Ce qui serait bien, c'est d'avoir un IDE comme Delphi pour Python avec les mêmes commodités, j'ai regardé Eric (pas moi, bien sûr), ça a l'air assez évolué.

On va revenir aux GUI de Python, je suis en train de regarder les exemples dans Kivy, c'est super joli et ça n'a pas l'air trop compliqué.

Si d'autres ont fait des essais, ce serait bien d'en parler. Je suis preneur.

Citation:

---

Envoyé par e-ric

Ce qui serait bien, c'est d'avoir un IDE comme Delphi pour Python avec les mêmes commodités, j'ai regardé Eric (pas moi, bien sûr), ça a l'air assez évolué.

---

Jetez un œil sur le wiki Python.
Comme je travaille dans plusieurs langages, utiliser des IDE trop colles au langage de programmation, ne me convient pas du tout.
- W

On sort un peu du sujet principal, mais la discussion est intéressante.

Concernant les EDI je pense que Eric reste un des plus performants pour du code écrit en PyQt.

Cependant il n'est pas, sauf erreur de ma part, encore parfaitement fait pour du PyQt 5.

D'autre part je regrette beaucoup qu'il n'intègre pas directement un "concepteur de GUI". En d'autres termes, le Designer.

Pour ces deux raisons j'ai migré sur Qt Creator. Il lui manque quelques fonctionnalités pour être aussi performant qu'Eric, mais selon moi uniquement si on souhaite créer une application en "PyQt pur". J'entends par là via le Designer.

Pour une application Qt Quick / Python c'est juste du pur bonheur.