Tu peux compiler un script python en bytecode Java (Jython) ou .Net (utilisable avec Mono bien sûr) avec IronPython (qui me semble légèrement mort en passant), mais je vois pas l'intérêt sous un système d'exploitation correct. Pour le système d'exploitation pas correct (désolé, la fatigue, toussa, on fait plus attention aux trolls), ya py2exe. Je sais que pygtk fonctionne avec py2exe, je crois que wxpython aussi (donc logiquement pyqt aussi), mais je sais pas comment ça se passe avec IronPython/Jython (tu peux bien sûr utiliser respectivement Swing/AWT/SWT et GTK#/WinForms, mais dans ce cas tu pourras plus utiliser ton programme dans un autre envitonnement comme CPytohn (le standard). Si tu fais du Swing/AWT/SWT, t'obliges l'utilisation de Jython, idem pour GTK# et IronPython. Quoique GTK# et pygtk ont peut être une API semblable, j'ai jamais touché à GTK#)
Mon avis personnel: Python + PyGTK permet de faire des chose vraiment étonnantes en quelques lignes de code avec un peu d'entraînement. Sous Linux, c'est relativement rapide (tu vas pas faire une application de calculs dessus, mais pour une application "normale", c'est largement suffisant). Sous Windows, tu as py2exe pour failiter la distribution. Bref, c'est le pied
J'ai également pendant un moment fait du GTK(mm/+)/C++, mais une fois que tu as goûté à la souplesse du python, tu ne peux plus t'en passer.
Pour être totalement subjectif, je vais te raconter mon expérience. J'ai eu à faire (pour besoins personnels) une application qui comportait un TreeView structuré de cette manière: 4-5 éléments de base qui contient chacun 1000 éléments fils qui contienent chacun 10 éléments fils. Soient 50 000 élements. J'ai commencé en GTK+/C++ par la méthode bourrin: on remplit tout d'un coup, et on laisse GTK+ se débrouiller avec le dépliage et toussa. Ca ramait à mort, et ça bouffait toute la RAM. Je me suis dit que je devrais calculer uniquement les éléments fils lors du dépliage. Ca ramait environ 2-3 secondes pour les gros dépliages (quand je dit que chaque racine à 1000 éléments, c'est très hétérogène: une en a 500, une autre 3000), mais c'était correct. Mais c'était ingérable en fait. Puis je suis passé en Python+PyGTK et je me suis dit "vu comment ça rame en C++, ça va pas être utlisable". Mais j'ai quand même essayé. Et là ça a été la révélation: grâce à la souplesse de Python, j'ai pu faire en sort que le calcul des sous-éléments se fasse uniquement lors de l'affichage [1]. En fait, contre la lenteur de Python, j'ai largement gagné par le fait que sa souplesse me permettait une architecture très peformante (en C++, ça aurait été facilement 5x plus de classes, méthodes, lignes de codes et erreurs possibles; en C, n'en parlons pas ;)). Ca ne ramait pas au démarrage, quelques millisecondes (à peine visble) aux énormes dépliages (en fait, je me suis permis 10 000 sous éléments et ça a pas ramé plus d'une demi-seconde). Ca saccadait légèrement lorsqu'on descendait rapidement, mais c'était tout.
[1] En entrant dans les détails techniques, je possédais un fichier XML à parser, possédant 5 gros éléments, qui possédaient quelques milliers de sous éléments (variable, de 500 à 10 000 en fait ;)) (qui eux même possédaient des sous éléments, mais ça n'a pas grande importance).
Première architecure: on parse tout, on fait tout dans le TreeView, et basta (ça rame horriblement au démarrage, et je vous explique pas l'occupation mémore...)
Seconde (C++): dès qu'on déplie on élément, alors seulement on crée ses éléments fils. Lorsqu'il y a 500 elems ça va, mais dès qu'on dépasse les 2000, ça rame. Et c'est déjà "lourd" de faire comme ça en C++
Troisième (Python): on dépliant un élément, on lui ajoute le nombre de fils qu'il possède (connus), mais vides: pas la peine de parser et de tout replir. On remplit que ce qui n'est visible, et lorsque la vue change (on scrolle, on redimensionne la fe,être), on renseigne les éventuels nouveaux éléments. Inmaintenanble en C++, une 100aine de lignes en Python, et drolement efficace pour un langage interprété...
[^] # Re: Original
Posté par Moonz . En réponse au journal Quel langage, pour cette utilisation ?. Évalué à 9.
Mon avis personnel: Python + PyGTK permet de faire des chose vraiment étonnantes en quelques lignes de code avec un peu d'entraînement. Sous Linux, c'est relativement rapide (tu vas pas faire une application de calculs dessus, mais pour une application "normale", c'est largement suffisant). Sous Windows, tu as py2exe pour failiter la distribution. Bref, c'est le pied
J'ai également pendant un moment fait du GTK(mm/+)/C++, mais une fois que tu as goûté à la souplesse du python, tu ne peux plus t'en passer.
Pour être totalement subjectif, je vais te raconter mon expérience. J'ai eu à faire (pour besoins personnels) une application qui comportait un TreeView structuré de cette manière: 4-5 éléments de base qui contient chacun 1000 éléments fils qui contienent chacun 10 éléments fils. Soient 50 000 élements. J'ai commencé en GTK+/C++ par la méthode bourrin: on remplit tout d'un coup, et on laisse GTK+ se débrouiller avec le dépliage et toussa. Ca ramait à mort, et ça bouffait toute la RAM. Je me suis dit que je devrais calculer uniquement les éléments fils lors du dépliage. Ca ramait environ 2-3 secondes pour les gros dépliages (quand je dit que chaque racine à 1000 éléments, c'est très hétérogène: une en a 500, une autre 3000), mais c'était correct. Mais c'était ingérable en fait. Puis je suis passé en Python+PyGTK et je me suis dit "vu comment ça rame en C++, ça va pas être utlisable". Mais j'ai quand même essayé. Et là ça a été la révélation: grâce à la souplesse de Python, j'ai pu faire en sort que le calcul des sous-éléments se fasse uniquement lors de l'affichage [1]. En fait, contre la lenteur de Python, j'ai largement gagné par le fait que sa souplesse me permettait une architecture très peformante (en C++, ça aurait été facilement 5x plus de classes, méthodes, lignes de codes et erreurs possibles; en C, n'en parlons pas ;)). Ca ne ramait pas au démarrage, quelques millisecondes (à peine visble) aux énormes dépliages (en fait, je me suis permis 10 000 sous éléments et ça a pas ramé plus d'une demi-seconde). Ca saccadait légèrement lorsqu'on descendait rapidement, mais c'était tout.
[1] En entrant dans les détails techniques, je possédais un fichier XML à parser, possédant 5 gros éléments, qui possédaient quelques milliers de sous éléments (variable, de 500 à 10 000 en fait ;)) (qui eux même possédaient des sous éléments, mais ça n'a pas grande importance).
Première architecure: on parse tout, on fait tout dans le TreeView, et basta (ça rame horriblement au démarrage, et je vous explique pas l'occupation mémore...)
Seconde (C++): dès qu'on déplie on élément, alors seulement on crée ses éléments fils. Lorsqu'il y a 500 elems ça va, mais dès qu'on dépasse les 2000, ça rame. Et c'est déjà "lourd" de faire comme ça en C++
Troisième (Python): on dépliant un élément, on lui ajoute le nombre de fils qu'il possède (connus), mais vides: pas la peine de parser et de tout replir. On remplit que ce qui n'est visible, et lorsque la vue change (on scrolle, on redimensionne la fe,être), on renseigne les éventuels nouveaux éléments. Inmaintenanble en C++, une 100aine de lignes en Python, et drolement efficace pour un langage interprété...
Bon, j'arrête là de m'étaler