UnicodeEncodeError seulement en cas de redirection

Bonjour,
Je m'arrache un peu (beaucoup) les cheveux sur python et l'unicode et j'aurai besoin d'un petit coup de main.

Voici le code :

Code:

---

1 2	# -*- coding: utf-8 -*- print u'é'

---

(Difficile de faire plus simple, vous en conviendrez ;))

et voici les différentes exécutions que j'en ai faites :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

$ python2.6 test.py é $ python2.6 test.py > /dev/null Traceback (most recent call last): File "test.py", line 2, in <module> print u'é' UnicodeEncodeError: 'ascii' codec cant encode character u'\xe9' in position 0: ordinal not in range(128) $ python3.1 test.py File "test.py", line 2 print u'é' ^ SyntaxError: invalid syntax

---

Donc mes questions sont les suivantes :
* Pourquoi python utilise un encodage différent suivant qu'on redirige la sortie ou pas et comment fait-il pour le savoir 8O?
* Pourquoi ce script simplissime, qui est passé pourtant par 2to3 provoque une erreur de syntaxe avec python 3 ?

Salut,

1/ je suppose que ton problème d'encodage est le même que celui-ci
http://www.developpez.net/forums/d95...s/#post5351789 : dans le cas d'une redirection (tout comme pour un pipe) sys.stdout.encoding renvoie None.

2/ Dans python 3, print est une fonction :

Code:

---

print("blabla")

---

Bonjour,
Ok le code :

Code:

---

1 2	# -*- coding: utf-8 -*- print u'é'.encode("utf-8")

---

fonctionne, mais bon, je me vois mal le mettre partout pour que, dans le cas où ma sortie serait redirigée, il n'y ait pas de faux bug qui apparaisse ! Ne peut-mon pas considérer ce comportement comme un bug ?
Bon, je râle, je râle, mais ça semble corrigé dans python 3.1, le code :

Code:

---

1 2	# -*- coding: utf-8 -*- print('é')

---

fonctionne, qu'il soit redirigé ou pas. Je vais essayer de coder en python 3 dorénavant, mais encore faudra-t-il que je trouve comment faire pour que macosx utilise python 3 par défaut et pas python 2.6 ...

Par contre, je ne comprend pas pourquoi 2to3 n'a pas utilisé la bonne syntaxe pour print...

Merci pour ton aide valAa

Salut,

Citation:

---

mais bon, je me vois mal le mettre partout pour que, dans le cas où ma sortie serait redirigée, il n'y ait pas de faux bug qui apparaisse ! Ne peut-mon pas considérer ce comportement comme un bug ?
Bon, je râle, je râle, mais ça semble corrigé dans python 3.1, le code :

---

La seule conclusion que vous pouvez tirer est que le fonctionnement par défaut de Python3 est plus proche de vos attentes que celui de Python2.6.

Lorsqu'on écrit u'é' sous Python2, "on dit" construit moi un tableau Unicode avec dedans la chaîne de caractère 'é' représentée selon la valeur du charset donné par # -*- coding: utf-8 -*-

Avec Python3, les string sont par défaut "unicode", plus besoin de mettre u.

Une fois réglée la transformation de la chaine entrée en Unicode...
On va peut être vouloir l'écrire dans un fichier....
Et donc transformer de l'Unicode dans la charset supporté par la "sortie".
Python2.x, le défaut est ascii sauf à avoir déclaré autre chose via sys.setdefaultencoding comme raconté dans ce post

- W

Citation:

---

Envoyé par huit_six

mais bon, je me vois mal le mettre partout pour que, dans le cas où ma sortie serait redirigée, il n'y ait pas de faux bug qui apparaisse ! Ne peut-mon pas considérer ce comportement comme un bug ?

---

J'ajouterais quelque chose. Pour moi, non, ce n'est pas un bug, et je m'explique.
Avec sys.stdout.encoding, python récupère l'encodage de ta sortie standard.
Mais lorsque tu utilise une redirection, ton script n'écrit pas sur la sortie standard mais, typiquement, dans un fichier.
Or je ne vois pas très bien comment python pourrait deviner l'encodage que tu souhaites utiliser dans ce fichier.

Pour moi la solution qui consiste à dire :
- je teste l'encodage de la sortie standard.
- s'il existe (le programme écrit sur la sortie standard), alors je l'utilise
- sinon, je force un encodage (ou j'utilise un encodage choisi par l'utilisateur via un argument par exemple)
Me paraît satisfaisante et rationnelle.

Je ne suis pas encore passé à python3 donc je vais peut-être dire des bêtises ici, mais peut-être que si cela fonctionne bien pour toi avec python3, c'est parce que l'utilisation automatique de l'unicode va avec une conversion implicite en UTF-8.
Dans ce cas, je ne suis pas sûr que l'utilisation de python3 dispense de se poser ce genre de questions (i.e « Dans quel encodage l'utilisateur/je veut la sortie de mon programme ?»), si on veut éviter que cela ne nous pète à la figure un jour ?

je viens de faire un test

Code:

---

1 2 3 4 5 6 7 8 9 10

#!/usr/bin/env python3 #-*- coding:utf-8 -*-   import sys   def main(): print('é') return 0   if __name__ == '__main__': main()

---

Je redirige la sortie de ce script python3 à la suite d'un fichier contenant déjà

Code:

---

éàù

---

et dont l'encodage est 'ISO-8859-1' (donc pas UTF-8).
Le fichier résultat

Code:

---

1 2

éàù é

---

Donc python3 ou pas, il faut quand même se poser la question de l'encodage en sortie, si on ne veut pas être confronté à des bugs un jour ou l'autre ;)

Citation:

---

Or je ne vois pas très bien comment python pourrait deviner l'encodage que tu souhaites utiliser dans ce fichier.

---

Et à quoi sert sys.setdefaultencoding alors? :cfou:

Citation:

---

Pour moi la solution qui consiste à dire :
- je teste l'encodage de la sortie standard.
- s'il existe (le programme écrit sur la sortie standard), alors je l'utilise
- sinon, je force un encodage (ou j'utilise un encodage choisi par l'utilisateur via un argument par exemple)
Me paraît satisfaisante et rationnelle.

---

Comme sys.setdefaultencoding définit toujours quelque chose, ce n'est pas "une solution"...
Et le problème reste entier si on doit transformer des caractères Unicode dans un charset réduit comme ASCII ou ISO-8859-1.
C'est ce qui fait préférer "utf-8" aux autres charsets.
- W

Citation:

---

Envoyé par wiztricks

Et à quoi sert sys.setdefaultencoding alors? :cfou:

---

À définir un encodage au niveau de l'installation de python.
Pas à deviner dans quel encodage pourrait bien se trouver un fichier existant dans lequel éventuellement notre script pourrait se trouver redirigé :aie: c'est juste ce que je voulais dire, et rien de plus.

Citation:

---

Envoyé par wiztricks

Comme sys.setdefaultencoding définit toujours quelque chose, ce n'est pas "une solution"...
Et le problème reste entier si on doit transformer des caractères Unicode dans un charset réduit comme ASCII ou ISO-8859-1.
C'est ce qui fait préférer "utf-8" aux autres charsets.

---

J'aurais du préciser.
Pour moi, laisser faire l'encodage défini par sys.setdefaultencoding revient à utiliser un encodage défini par l'utilisateur pour son install python. Ce n'est pas un problème, mais pour le développeur, c'est un choix. Il faut l'assumer (et ne pas dire "c'est un bug de python").
Le développeur du script python doit donc, python3 ou pas, faire des choix sur la manière de gérer l'encodage des I/O...
ou au moins se poser des questions.
Mais je crois bien qu'on est d'accord là dessus.

Moi ce qui me pose problème, c'est qu'on demande au développeur de l'application de se poser la question de ce que l'utilisateur va vouloir faire de ce qui sera écrit sur la sortie (stocker dans un fichier ? rediriger ? jeter ?) Or comment le développeur pourrait le deviner ?

Selon moi, mon programme (ou sa doc) est sensé indiquer quel est l'encodage utilisé pour ses sorties et l'utilisateur est sensé faire avec. Si python décide de changer l'encodage en fonction de l'utilisation, je trouve ça risqué car imprévisible.

Concernant ce bug (en tout cas de mon programme), le hasard a voulu que je veuille trier la sortie et l'erreur standard de mon programme, qui était très verbeux, pour détecter les éventuels bugs. Or c'est cette redirection qui a créé un bug alors que mon programme fonctionnait. (heisenbug on dit je crois ?)
Finalement c'est le hasard qui m'a fait m'en rendre compte, or mon logiciel est un petit serveur, pour lequel on pourrait être amené à enregistrer les logs et le bug aurait pu arriver bien plus tard et me faire sacrément plus me gratter la tête (sachant que j'ai déjà pas mal gratouillé http://forum-images.hardware.fr/imag...so/chamois.gif)

Sinon, pour ce que j'ai compris, setdefaultencoding ne doit pas être utilisé et est carrément dé-défini (Comment on dit ça ???) après utilisation dans site.py je crois.

Mais ceci dit, je comprends tes arguments que je trouve très intéressants.

Personnellement, je vais essayer de tout porter sur python 3 vu que je suis pas encore trop avancé dans mon projet. Je pense que ça pourra m'apporter pas mal, notamment pour cette question de l'encodage.

Salut,

Citation:

---

Moi ce qui me pose problème, c'est qu'on demande au développeur de l'application de se poser la question de ce que l'utilisateur va vouloir faire de ce qui sera écrit sur la sortie (stocker dans un fichier ? rediriger ? jeter ?) Or comment le développeur pourrait le deviner ?

---

Je suis d'accord, le développeur n'est pas devin... mais c'est lui qui tient le crayon et son programme qui effectue les entrées/sorties. Il doit donc au moins dire un truc du style je ne sais lire et écrire que de l'utf-8.
Et s'assurer/modifier le default encoding pour que çà le fasse.

Citation:

---

Sinon, pour ce que j'ai compris, setdefaultencoding ne doit pas être utilisé et est carrément dé-défini (Comment on dit ça ???) après utilisation dans site.py je crois.

---

Yup mais c'est Python... donc on peut faire ce qu'on veut pourvu que ce ne soit pas n'importe quoi.
Exemple:

Code:

---

1 2 3

import sys reload(sys) sys.setdefaultencoding('utf-8')

---

Citation:

---

Personnellement, je vais essayer de tout porter sur python 3 vu que je suis pas encore trop avancé dans mon projet. Je pense que ça pourra m'apporter pas mal, notamment pour cette question de l'encodage.

---

Si vous n'avez pas de dépendances avec des bibliothèques non encore disponibles, pourquoi pas...
Mais:

Citation:

---

mon logiciel est un petit serveur

---

Vous allez recevoir et émettre des "bytes" et non des "strings" Unicode.
La moins mauvaise démarche est de faire les conversions au plus près des IO pour réduire les ambiguités sur la nature bytes/strings d'une "chaine de caractères": le cœur du code travaillant en Unicode.

Dans le cas d'une application réseau, il y a généralement une structure en
couches qui rend la démarche raisonnable dans le cas général discutable sur les aspects utilité/performances/testabilité.
La frontière entre bytes <=> Unicode "glisse" vers le coeur...

L'avantage de Python3 sera de vous obliger à tracer la frontière et préciser ou vous travaillez avec des bytes et où vous vous attendez à voir des "strings". Python2 permettait un certain laxisme pas forcément gênant...
Après çà dépend du serveur....
Le pompon revenant à HTTP: commandes ASCII, headers ISO-8859-1, URL en UTF-8, et pour le body... c'est pas toujours très clair...
- W

En effet, je viens de faire la migration et ça s'est passé pas trop mal :D. Surtout, au niveau de l'encodage, j'y ai gagné en clarté, en gros, tout en interne dans mon programme se passe en utf-8 avec des chaînes et quand ça transite par le réseau, j'encode en bytes.

Comme vous dites, au plus près des I/O, ça me semble être ce qu'il y a de plus clair. Et surtout ça regroupe en un seul point très limité, tout ce qui a un rapport avec l'encodage.

Franchement ça marche pas mal du tout, ça va m'aider à avancer. Je regrette pas ma tentative python3...

Merci beaucoup du coup de main ! :ccool: