ben en fait, je ne sais pas trop
DIsont que j'espérait pouvoir utiliser cette petite routine pour allimenter une interface avec un refresh toutes les x secondes pour les trucs qui changent (le status du GW Sip, par exemple)
Mais là, j'ai peur que ce ne soit pas possible.
Ou alors, il faut que je fasse les choses autrement.
Càd en faisant la connexion HTTP une fois et en allant juste rechercher les infos sans tout refaire.
Je ne sais pas encore.

Ça veut dire quoi, très lent ?
Et as-tu une idée de ce qui prend du temps dans le script ? Peut-être est-ce juste la connexion http...

J'ai encore une question
Quand j'exécute mon petit script, c'est très lent.
Est-ce que c'est normal?
Le script est dans le spoiler.

Tu as py2exe pour windows, wx_freeze pour linux, et un autre dont je ne me souviens plus le nom.

En fait, ca te crèe un package ou toutes les librairies sont embarquées. Ca peut donc prendre de la place si tu as beaucoup de librairies externes utilisées

Pour recentrer un peu la discussion...

Est-il simple de faire des packages pour les différentes plateformes?
Histoire que ce soit utilisable sans devoir installer python, wxPython et tout le brol.

Merci

Fonction non implémentée, ToDoList qu'il disait

Sans doute, mais la structure header/body des e-mails (RFC822) existait avant MIME et avant content-type, et ne connaissait que l'US-ASCII 7 bit.
Ajouter des headers pour spécifier l'encodage du body était possible et a permis MIME.
Mais ajouter des pre-headers pour spécifier l'encodage des headers...???

Tu peux d'ailleurs t'estimer heureux que beaucoup de MTA (postfix/exim/...) et de mailers acceptent des contenus sur 8 bits dans les bodies. Normalement, tous les encodages qui nécessitent le 8ème bit doivent être convertis en quoted-printable ou base-64.

Mais on s'éloigne de python... Si tu splittais le topic ?

C'est en UTF-16 en effet, mais je repasse tout en UTF-8 pour l'affichage vu que même niveau browser, c'est pas toujours évident un UTF-16 (ni pour les mailers, déjà l'UTF-8 ils ont du mal).

Quand j'envoie un mail, il est justement explicitement en UTF-8 cfr l'encoding, donc pas besoin que je fasse quoi que ce soit. Le sujet devrait d'ailleurs aussi être traité comme étant de l'UTF8 si on reste logique avec le :

Content-Type: text/plain; charset=UTF-8

C'est pas le cas, ok, mais ce serait logique que le sujet soit dans le même charset que le content et qu'on doive pas l'encoder

Quand tu dis unicode, tu dois vouloir dire UTF-8, UTF-16, ou UCS-4... Implicitement ou explicitement, il faut convertir l'encodage que tu utilises pour l'unicode vers l'encodage acceptable pour un header ou un body MIME.

Et tu as bien plus de chances de tomber sur un mailer qui ne saura rien faire avec ton header unicode que sur un mailer qui ne comprend pas un header encodé selon RFC2047...

Mais on est d'accord: il faudrait un API "set_default_encoding" qui influence tous les APIs de génération d'emails.
Il y a sûrement un moyen trivial de faire ça en Python...

philfr> Je ne suis pas programmeur python, mais une indentation foireuse devrait être sanctionnée par le compilo, je suis bien d'accord. Ou au moins balancer des warnings, parce que c'est illisible un code mal indenté (mais je me contenterais d'un warning quand même)

Ah mais évidemment pour le mail, tu passes par un encodage explicite. Pour ma part, tout est en full unicode dans Kelare, si PHP pouvait proposer des APIs qui fonctionnent avec l'unicode, je n'aurais pas ce "problème".

Je pourrais pour la forme l'encoder moi même, je te l'accorde, mais j'ai pas envie que le sujet soit bousillé sur un client qui ne le supporte pas, et je dois dire que j'ai la flemme de devoir contourner un problème qui devrait être réglé avec une fonction mail qui serait en unicode