Bonjour !

J'ai un script qui tourne, lance, régulièrement (toutes les 15 minutes), des morceaux de code se
trouvant dans un fichier.

Le morceau qui me pose problème, c'est :

data=pd.iip()+" (le "+time.strftime("%d.%m.%Y")+u", à "+time.strftime("%H:%M:%S")+")"


Le problème :

Lorsque le script est lancé avec python.exe, tout fonctionne (testé sur 36 heures).
Lorsque le script est lancé avec pythonw.exe, ça bloqué sur la ligne citée plus haut.

Mais, si je remplace le milieu +u", à "+
par +u", a "+
ça marche dans tous les cas.


Quelques précisions :
- ça tourne dans un thread séparé, mais, pour les tests, il n'y a plus qu'un seul thread.
- ça tourne sur une machine distante, à laquelle je n'ai accès que par télémaintenance.
- évidemment, je n'ai pas de TraceBack
- c'est sous Windows-2003-serveur (en français)
- je n'ai pas testé sur d'autres machines


Je m'arrache les cheveux à essayer de comprendre pourquoi l'accent sur la "a" pose problème.


Bon, OK, j'ai trouvé une solution qui marche (sans l'accent) ; mais j'aimerais bien comprendre.


Est-ce que quelqu'un a une idée ? Ou quelqu'un a-t'il constaté d'autres écarts python vs pythonW ?


@+

Michel Claveau

Méta-MCI (MVP) wrote:
> Est-ce que quelqu'un a une idée ? Ou quelqu'un a-t'il constaté d'autres
> écarts python vs pythonW ?

Q? (because unicode et accents): As-tu la bonne directive d'encodage dans le
source ?

[du genre un problème d'un exception dont la trace irais vers stdout... mais
stdout c'est quoi avec pythonw?]

Salut !

Il doit bien y avoir un problème d'encodage quelque part.
Mais :
- les morceaux de codes-source à traiter arrivent dans une chaîne de caractères (ce sont des
tâches à effectuer, qui viennent, par un fichier, par e-mail, par TCP/IP, par mmap ; pour les tests,
j'ai limité au canal fichier).
- chaque morceau de code-source est compilé en un objet-code, pour vérifier qu'il n'y a pas
d'erreur de syntaxe
- l'exécution elle-même est séparée de la réception/compilation du code-source.

D'habitude, lorsque je fait ça, un problème d'encodage est détecté au moment de la compilation.
Mais, ici, la phase de compilation passe sans problème. De plus, il ne faut pas mettre de directive
d'encodage dans une chaîne-source, car sinon, ça provoque (souvent) une erreur.


Mais, bon, il faudrait que :
- je teste sur d'autres Windows
- je teste sur d'autres machines.
- je tente de récupérer le traceback dans un fichier
- je fasse des tests sans multi-threading
- etc.
Mais, je ne suis guère motivé, vu que ça marche (sans accents), et que j'ai plein de travail par
ailleurs ; ça attendra bien un peu.

En tout cas, merci de t'être penché sur le problème.

@+

Michel Claveau

Laurent Pointal a écrit :
> M�ta-MCI (MVP) wrote:
>> Est-ce que quelqu'un a une idée ? Ou quelqu'un a-t'il constaté d'autres
>> écarts python vs pythonW ?
>
> Q? (because unicode et accents): As-tu la bonne directive d'encodage dans le
> source ?
>
> [du genre un problème d'un exception dont la trace irais vers stdout... mais
> stdout c'est quoi avec pythonw?]
>
>
D'accord avec Laurent.
Dans le même genre, j'ai un script Python qui passait sans problème quand il était lancé à partir de la ligne de commande mais qui plantait quand il était lancé à partir de IDLE.
Le script récupère un fichier XML avec urllib sur une machine distante, le parse et affiche certains champs. Les affichages des champs contenant des caratères non-ascii plantaient. J'ai dû explicitement convertir ces champs en unicode (en forçant l'encodage) avant de les afficher pour que ça marche dans tous les cas.

Nicolas

Salut !

Ce qui me semble bizarre, c'est que les mêmes scripts fonctionnent avec python.exe, et pas avec
pythonw.exe.
Mais, est-ce que la gestion du stdout est identique, dans les deux cas ?

De toutes façons, comme ça m'énerve de pas comprendre, je vais me monter des configs de test, dans
l'après-midi...


@+

Michel Claveau

Bonjour !


Résultats de quelques tests : Horreur ! Le problème est présent sur deux machines, parmi les 6 sur
lesquelles j'ai fait des tests.
De plus, comme ces deux machines sont des serveurs (W2KS), chez des clients, pas question de
bricoler les configs, pour tester...

Conclusion : y'a bien un truc, facile à contourner, sur un périmètre restreint, mais inconnu.


@+

MCI