Discussion :

[huit_six]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?
* Pourquoi ce script simplissime, qui est passé pourtant par 2to3 provoque une erreur de syntaxe avec python 3 ?

[valAa]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

print("blabla")

[huit_six]

Bonjour,
Ok le code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[wiztricks]

Salut,

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

[valAa]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

éàù

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[wiztricks]

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?

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

[valAa]

Et à quoi sert sys.setdefaultencoding alors?

À 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é c'est juste ce que je voulais dire, et rien de plus.

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.