Explications

Comme je l'ai dit avant, Python "cay bien", le seul problème ici c'est que j'ai fait le choix d'utiliser la version 3.0 qui n'est pas rétrocompatible... Cela dit, je m'en foutais dans la mesure où après avoir évalué mes besoins, je ne comptais utiliser que la ligne de commande (et je n'avais besoin que des librairies standards) :hehe: .

Bon, le projet commence, mes scripts marchent à merveille:

  • Renommage des fichiers exportés par Finalcacacut (Qu'on ne vienne pas me dire que Mac en prod ça déchire, j'ai un surplus d'arguments allant dans le sens inverse à gérer...)
  • Cherchage d'erreurs dans les nomenclatures des fichiers: "Pourquoi c'est là ça?", "Il manque un tiret à ton nom de fichier", etc...
  • Comparaison des fichiers et update par exécution de programme en ligne de commande automatiquement: "Fichier .tiff plus récent que fichier .map, conversion...", "Fichier .map absent mais fichier .tiff présent, conversion...", etc...
  • Frame "checkage": "Image E01P001_color.tiff de 0 octet", "Image E01P001_color.tiff de 128 octet -> Erreur mental ray probable", etc...

Bref, que du bonheur... :youplaBoum:

Toujours plus!

Mais voila, au fur et à mesure de mon avancement, je me suis fait une lib de petites fonctions bien pratiques et j'ai voulu commencer à faire une petite interface graphique pour tout ça... En toute logique, je commence avec tkinter (une lib graphique vieille comme pas permis mais intégrée en standard à Python 3.0, je la trouve bien moins puissante que le mel, même pour des choses "simples"). Pour ce que je voulais faire (au début), c'était largement suffisant. Quelques colonnes et puis c'était bon...

ecureuil_001.png

Mais comme tout bon (ou mauvais) projet, on se met à vouloir (et devoir) faire évoluer son outil et les besoins en terme de "possibilités" grandissent... Bon, mon interface étant très simple, et voyant le truc venir, je commence à me tourner vers d'autres tool kits graphiques. Et là, je me prends un mur dans les dents (c'est l'effet Python 3.0), à savoir, tous les portages des librairies graphiques les plus connus sont actuellement sous Python 2.x. En effet, Python 3.0 n'était pas rétroactive, la plupart des projets sont frileux à l'idée de passer à la nouvelle version. J'ai trouvé un post d'une personne qui semble être impliquée dans un projet (wxPython, on y reviendra) disant que le portage n'est pas prévu....

- "Hi, I was wondering if there are already any plans when or how wxPython will support/start moving to python 3? Are there a lot of issues involved with porting wxPython framework? (I don't mean user programs.) I know it is still a bit early but as it is coming closer maybe there is a roadmap already."

- "Nothing solid yet. I've got a general idea of things that will likely need to be done, but haven't yet confirmed any of it or done any real investigations."

Qu'a cela ne tienne, mes scripts étant relativement simples, je vire la version 3.0, installe la version 2.6.1 et corrige mes script pour les rendre compatibles: 15 minutes... Aux vues de l'investissement que ça représentait, je n'étais, à priori pas perdant au change dans la mesure où j'allais me retrouver avec une "vraie" lib graphique qui n'allait pas me limiter (comme le fait tkinter).

Après un aperçu rapide des libs graphiques existantes je remarque une certaine sympathie des utilisateurs pour la librairie wxPython. En ayant déjà entendu parlé, je décide de m'y tenter.

"Quand les emmerdes arrivent c'est moi qui interviens..."

J'installe tout ça (avec la "doc et démos" qui est extrêmement bien faite, et je pèse mes mots) et commence à lancer une fenêtre, tout marche bien mais dès que je place mon curseur sur la dite fenêtre, python plante (avec envois de rapport d'erreur et tout...). Je continue, utilise différents exemples... Défois ça marche, défois pas (ça fait très débordement de mémoire)... Je cherche sur le forum et je trouve un type dans le même cas que moi, un système 64bits. Il renvoi à un rapport de bug. Le problème est donc connu mais non résolu. C'est spécifique aux systèmes 64bits...

"Same problem here with wxPython2.8-win32-unicode-2.8.9.1-py26 under Vista Ultimate x64. Simple applications crash as soon as one moves the mouse onto their window. More complicated applications seem to work fine. Even the demo crashes if you move the mouse onto the splashscreen. If you leave the mouse outside the spashscreen and let it disappear, the demo seams to run fine."

Naïvement, je désinstalle mon wxPyhon et mon Python, tous deux en 64bits, puis réinstalle le tout en 32bits... Même problème. :mechantCrash:

Je commence à réfléchir aux alternatives et n'en voit qu'une seule: Passer à Python 2.5...

(Edit: Une personne semble avoir trouvé une solution mais c'est pas ce qu'il y a de plus propre disons...)

Bon, là ça commence à me gonfler un peu. Après une longue réflexion, je décide de rester sous Python 3.0 avec tkinter. Pourquoi? J'en sais trop rien en fait... Ça me fait bizarre de repasser sous une ancienne version de Python. Mais surtout, j'ai pris conscience de quelque chose: le support est assuré uniquement sur les librairies standard... En gros, tous les portages ne sont pas assurés dans le temps (j'en veux pour preuve la grande quantité de lib python qui ne sont plus maintenus) ce qui fait que si on veut être sûr d'avoir quelques chose qui dure dans le temps, il faut rester sur les librairies standards.

tkinter!

C'est ici que commence le billet en fait. Tout le début était une intro. :sauteJoie:

Je continue donc ma petite interface sous tkinter. Sauf que voila, la documentation est désastreuse...

Pour résumer, disons que:

  • Il n'y a pas de "vrai doc ultime"
  • Elle est éparpillée sur le net
  • Les exemples datent et ne sont plus adaptés à Python 3.0 (L'effet Python 3.0 que je citais plus haut)

On s'amuse donc comme un petit fou à tenter tout et n'importe quoi pour réussir certaines manipulations, à trouver une bride d'infos qu'on retranscrit comme on peut (j'ai du aller regarder directement dans les libs py pour savoir comment faire certaines choses :baffed: ). Allez trouvez un moyen de lancer une FileDialog sous Python 3.0, le truc de base à faire. J'ai cru qu'au final j'allais devoir me rescripter une FileDialog. Soit je suis nul, soit ça prouve que c'est un peu la misère, (non pas à faire, mais ça se devine pas... Et sans doc, on est comme un imbécile). Au final, on trouve mais en mettant en relation différentes documentations. Pour mon exemple:

  • "FileDialog" est un sous module de tkinter (Doc1)
  • Il faut l'appeler avec "asksaveasfilename" (Doc2) (Ne me dites pas que ça se devine...)
  • L'attribut pour lui mettre un path par défaut est "initialdir" (Doc3)

Super! Maintenant (après plus d'une heure), j'ai une FileDialog. :casseTeteMur:

La raison pour laquelle j'ai créé ce billet est la suivante: J'ai tellement galèré pour trouver des morceaux de documentation que je vous propose de les lister ci-dessous (Tout est en vrac mais au moins, vous en avez déjà pas mal).