Premiers pas dans le monde de Python

Bonjour à tous,

Après avoir fait quelques formation pour débutant sur python (votre site et aussi sur OC) j'aimerais bien tester la partie "interface graphique".
En cherchant, j'ai vu des noms comme PyGObject, Glade ...
Déjà est ce trop tôt pour moi de m'y pencher ?
Sinon quel programme vous me conseillez pour bien débuter dans la partie interface ? Et après quand je serais plus "avancés" ?

Je rencontre aussi un petit soucis pour faire une application "standalone" (si j'ai bien compris), j'utilise depuis le début la version Python 3.5 et apparemment pour que mon code soit fonctionnel sur divers os le mieux serait d'utiliser cx freeze, or celui-ci n'est pas encore compatible avec la v3.5, est ce qu'une version cx freeze est prévue pour la 3.5 ?

Merci pour vos conseils ;)

Salut,

Citation:

---

Envoyé par Julianinho

Après avoir fait quelques formation pour débutant sur python (votre site et aussi sur OC) j'aimerais bien tester la partie "interface graphique".
En cherchant, j'ai vu des noms comme PyGObject, Glade ...
Déjà est ce trop tôt pour moi de m'y pencher ?
Sinon quel programme vous me conseillez pour bien débuter dans la partie interface ? Et après quand je serais plus "avancés" ?

---

Les soucis avec toute bibliothèque graphique sont:

• passer d'une programmation séquentielle à une programmation évènementielle ou pilotée par les évènements,
• maîtriser la POO car vous vous retrouvez assez rapidement avec beaucoup de widgets à gérer. Savoir organiser son code via les constructions offertes par la POO sont un plus.

Pour le choix d'une bibliothèque graphique, je suis sans opinion: elles se valent à peu près toutes après c'est une question de documentation, de style de programmation, ... et éventuellement de complexité de vos applications. Je dirais qu'il faudrait prendre le temps de faire son opinion. Pour ma part, je code avec ce que le client veut et quand je peux choisir je préfère utiliser tkinter: c'est simple et safisfaisant dans 90% des cas.

[

Citation:

---

Envoyé par Julianinho

]Je rencontre aussi un petit soucis pour faire une application "standalone" (si j'ai bien compris), j'utilise depuis le début la version Python 3.5 et apparemment pour que mon code soit fonctionnel sur divers os le mieux serait d'utiliser cx freeze, or celui-ci n'est pas encore compatible avec la v3.5, est ce qu'une version cx freeze est prévue pour la 3.5 ?

---

Cette version de Python n'est sortie que depuis quelques semaines. Un peu trop top pour que toutes les bibliothèques soient disponibles et que tous les bugs soient corrigés. Si vous développez, rester en 3.4 ou en 3.3 est une bonne option en attendant que la 3.5 soit sèche.

- W

Citation:

---

Envoyé par wiztricks

Salut,



Les soucis avec toute bibliothèque graphique sont:

• passer d'une programmation séquentielle à une programmation évènementielle ou pilotée par les évènements,
• maîtriser la POO car vous vous retrouvez assez rapidement avec beaucoup de widgets à gérer. Savoir organiser son code via les constructions offertes par la POO sont un plus.

Pour le choix d'une bibliothèque graphique, je suis sans opinion: elles se valent à peu près toutes après c'est une question de documentation, de style de programmation, ... et éventuellement de complexité de vos applications. Je dirais qu'il faudrait prendre le temps de faire son opinion. Pour ma part, je code avec ce que le client veut et quand je peux choisir je préfère utiliser tkinter: c'est simple et safisfaisant dans 90% des cas.

[

Cette version de Python n'est sortie que depuis quelques semaines. Un peu trop top pour que toutes les bibliothèques soient disponibles et que tous les bugs soient corrigés. Si vous développez, rester en 3.4 ou en 3.3 est une bonne option en attendant que la 3.5 soit sèche.

- W

---

Merci pour vos conseils !
Je viens de télécharger la v3.4 de Python (sur vos conseils), je vais pouvoir m'entrainer un peu avec cxfreeze, c'est tout nouveau encore pour moi.

Pour l'interface graphique, j'ai commencé avec tkinter hier, je l'utilise actuellement, à vrai dire mon 1er code que j'ai réussi à faire c'est avec lui, un truc tout simple que j'ai mis en place, ça consiste à dire tel fichier qui porte l’extension .Part sera supprimé dans tel dossier, je l'ai fais en interface avec une petite fenêtre, mais bon ce n'est qu'un début, rien de bien extraordinaire ^^
Sinon je ne savais pas que Tkinter faisait partie aussi de la ligné avec Glade, PygObject...

Edit : je viens de réussir à transformer un fichier .py en .exe avec cxfreeze, mais quand je lance le .exe (sur un autre pc sans python d'installé) j'ai une erreur disant qu'il manque "python34.dll" (que j'ai vu dans le dossier build situé dans le dossier python), doit on à chaque fois envoyer le .exe avec la dll correspondante pour que la personne puisse lancer mon code ou c'est une mauvaise manip de ma part avec cxfreeze ?

Citation:

---

Envoyé par Julianinho

Edit : je viens de réussir à transformer un fichier .py en .exe avec cxfreeze, mais quand je lance le .exe (sur un autre pc sans python d'installé) j'ai une erreur disant qu'il manque "python34.dll" (que j'ai vu dans le dossier build situé dans le dossier python), doit on à chaque fois envoyer le .exe avec la dll correspondante pour que la personne puisse lancer mon code ou c'est une mauvaise manip de ma part avec cxfreeze ?

---

Normalement, çà a besoin de tout ce qui est dans le répertoire build.win32-3.4(*).
Une DLL (ou une librarie partagée) est chargée en mémoire via un mapping du fichier dans l'espace mémoire.
Cette opération (de mapping) est réalisée par le "chargeur", un engin spécifique à l'OS qui s'occupe lorsqu'on tape "run program" de construire l'espace virtuel (avec le mapping des DLL et le "fixup" des vecteurs de transfert): impossible de mettre les DLL dans un executable en espérant que le loader"chargeur" s'en sortira. Il faut les poser à côté. Certains programmes équivalent à cx_freeze s'en sorte en unzippant les DLL dans un répertoire temporaire.
(*) l'étape suivante serait de construire un packages qui soit "installable" comme d'autre application windows i.e. après le "build" relancer avec un bdist_msi" par exemple.

- W

Citation:

---

Envoyé par wiztricks

Normalement, çà a besoin de tout ce qui est dans le répertoire build.win32-3.4(*).
Une DLL (ou une librarie partagée) est chargée en mémoire via un mapping du fichier dans l'espace mémoire.
Cette opération (de mapping) est réalisée par le "chargeur", un engin spécifique à l'OS qui s'occupe lorsqu'on tape "run program" de construire l'espace virtuel (avec le mapping des DLL et le "fixup" des vecteurs de transfert): impossible de mettre les DLL dans un executable en espérant que le loader"chargeur" s'en sortira. Il faut les poser à côté. Certains programmes équivalent à cx_freeze s'en sorte en unzippant les DLL dans un répertoire temporaire.
(*) l'étape suivante serait de construire un packages qui soit "installable" comme d'autre application windows i.e. après le "build" relancer avec un bdist_msi" par exemple.

- W

---

Ok je comprends mieux !
Je sais pas pourquoi je mettais mis en tête que j'allais en faire 1 fichier unique, j'avais mal compris le principe.
Donc quand je vais créer d'autres programmes (pour mes clients par exemple), je devrais leur envoyer le dossier build avec tout ce qui s'y trouve, dans mon cas j'ai des fichiers "PYD", mon .exe, "python34.dll" et "library.zip"

Sinon j'espère avoir pris la bonne décision en choisissant cxfreeze par rapport à d'autres équivalents sachant que je veux que mes programmes soient fonctionnel sur divers os le plus facilement possible. Si je me trompe pas j'ai vu en parcourant le forum tout à l'heure un tuto que vous avez fais sur cxfreeze donc je suppose que vous en êtes satisfait ;)

Salut,

Citation:

---

Envoyé par Julianinho

Sinon j'espère avoir pris la bonne décision en choisissant cxfreeze par rapport à d'autres équivalents sachant que je veux que mes programmes soient fonctionnel sur divers os le plus facilement possible. Si je me trompe pas j'ai vu en parcourant le forum tout à l'heure un tuto que vous avez fais sur cxfreeze donc je suppose que vous en êtes satisfait ;)

---

Ce doit être un tuto. pondu par Tyrtamos.

Pour l'utiliser correctement, vous devez comprendre comment construire votre code. Dans la documentation Python c'est documenté ici. Si vous y jetez un œil, vous verrez que cette partie de la documentation est en chantier car la communauté Python travaille à remplacer distutils sur lequel est basé cx_freeze.

- W

Citation:

---

Envoyé par wiztricks

Salut,



Ce doit être un tuto. pondu par Tyrtamos.

Pour l'utiliser correctement, vous devez comprendre comment construire votre code. Dans la documentation Python c'est documenté ici. Si vous y jetez un œil, vous verrez que cette partie de la documentation est en chantier car la communauté Python travaille à remplacer distutils sur lequel est basé cx_freeze.

- W

---

Salut,

Je vais jeter un oeil sur tout ça.
Merci pour tout vos conseils.