[résolu] python et encodage des caractères.

pépère · Le 22/08/2007, à 09:29

Salut !

Je sais que ce genre de question a déjà été posé, mais y'a un truc que je ne comprend vraiment pas.

Je crois que j'ai compris l'importance de spécifier l'encodage des chaines de caractères utilisés. J'essaie pour le moment de faire joujour avec les conversions...

Mais je ne comprend pas cette séquence de commandes :

a = u'\xe9l\xe9phant'
a
print a

b = [a]
b
print b

Cela donne :

>>> a = u'\xe9l\xe9phant'
>>> a
u'\xe9l\xe9phant'
>>> print a
éléphant
>>> 
>>> b = [a]
>>> b
[u'\xe9l\xe9phant']
>>> print b
[u'\xe9l\xe9phant']

1) je croyais que 'a' (ligne 2) était un raccourci à la commande 'print a' : mais dans un cas, l'affichage du mot éléphant se fait dans son codage 'source', et dans l'autre, les lettres accentuées s'affichent.
2) quand je met 'a' dans une liste 'b' (ligne 5), la commande 'print b' affiche l'encodage 'source'... Pourquoi l'affichage se fait-il correctement pour une chaine de caractères (par "correct", je veux dire avec les lettres accentuées...), mais pas pour les chaines de caractères contenues dans une liste ?

Voilà, désolé de vous embêter avec ça... J'ai compris quelques trucs en lisant cette page : http://sebsauvage.net/python/charsets_et_encoding.html

Je vois grâce à elle l'importance d'indiquer quel est le codage utilisé... J'ai aussi lu le topic http://forum.ubuntu-fr.org/viewtopic.php?id=69733

Il semble que Shuriken ait eu un problème semblable, mais je n'ai pas compris les explications d'aleph, qui dit en substance

"Encodé correctement le texte sera affiché."

Mais il me semble que mon texte est bien encodé...

Voilà, je vous remercie pour toute aide...

Dernière modification par pépère (Le 23/08/2007, à 13:41)

bipede · Le 22/08/2007, à 10:56

pépère a écrit :

Salut !
1) je croyais que 'a' (ligne 2) était un raccourci à la commande 'print a' : mais dans un cas, l'affichage du mot éléphant se fait dans son codage 'source', et dans l'autre, les lettres accentuées s'affichent.

Non :

>>> a

te montre ce qui est stocké dans la variable a

>>> print a

t'affiche le contenu formaté de la variable a

pépère a écrit :

2) quand je met 'a' dans une liste 'b' (ligne 5), la commande 'print b' affiche l'encodage 'source'... Pourquoi l'affichage se fait-il correctement pour une chaine de caractères (par "correct", je veux dire avec les lettres accentuées...), mais pas pour les chaines de caractères contenues dans une liste ?

Quand tu lances

>>> print b

Tu demande à python de t'afficher la liste formatée en liste et non pas de t'afficher le contenu formaté de ta liste.
Si tu écris

>>> print b[0]

Il t'affichera

éléphant

pépère a écrit :

Il semble que Shuriken ait eu un problème semblable, mais je n'ai pas compris les explications d'aleph, qui dit en substance
"Encodé correctement le texte sera affiché."
Mais il me semble que mon texte est bien encodé...

Ton texte est encodé avec l'encodage par défaut de ton système (visiblement c'est de l'utf-8).
Si tu ne connais pas cet encodage par défaut, tu peux difficilement le décoder correctement pour le transformer en str.
Si tu veux maitriser l'affichage de tes chaînes, le mieux est de travailler en unicode et de préciser l'encodage, puis de décoder lorsque tu as besoin d'un str .
Ci-dessous un exemple qui fonctionnera en console python sous windows comme sous ubuntu :

>>> s1 = u"éléphant".encode('utf-8') #encodage en utf-8
>>> print s1
éléphant
>>> s2 = s1.decode('utf-8') #Constitution d'un str par décodage
>>> print s2
éléphant

Les contenus des variables s1 et s2 sont différents, mais leur formatage pas print est le même.

pépère · Le 22/08/2007, à 13:00

ok, je crois que je commence à comprendre...

Mais j'ai encore quelques petits trucs :
- A quoi sert de préciser dans l'entête que mon script est écrit en utf-8 (# -*- coding:Utf-8 -*-), puisqu'on doit indiquer l'encodage utilisé à chaque fois qu'on fabrique une chaine de caractères ?
- la première de tes commandes encode u"éléphant" en utf-8. Mais "éléphant" est codé en quoi à l'origine ? Comment python arrive-t-il à le "traduire" en utf-8 alors qu'on indique pas l'encodage ? D'après ce que j'ai lu (et cru comprendre), le "u" juste avant "éléphant" dit juste qu'on veut utiliser le charset unicode, mais ne précise pas le codage de la chaine "éléphant"... C'est pour ça que dans mon premier poste, je n'ai pas mis directement les lettres accentuées, mais leur numéro unicode. Ce n'est pas très pratique, mais j'avais l'impression qu'on avait pas le choix...
- Tu as bien deviné concernant le codage de mon système (par défaut de ubuntu). Mais j'ai essayé tes commandes au boulot, sous windows XP, et tes deux premières commandes ne renvoie pas le bon affichage (mais les suivantes oui) :

>>> s1 = u"éléphant".encode('utf-8') #encodage en utf-8

>>> print s1
éléphant

>>> s2 = s1.decode('utf-8') #Constitution d'un str par décodage

>>> print s2

éléphant

- j'ai l'impression qu'il n'y a pas de moyen de dire à python dans un programme d'utiliser et d'afficher le charset et l'encodage par défaut du système où il tourne. Me trompe-je ?

Dernière modification par pépère (Le 22/08/2007, à 13:03)

pépère · Le 22/08/2007, à 15:06

Bon, je crois que j'ai mieux compris :
- ta première commande encode une chaine unicode en utf-8
- du coup, elle ne s'affichera pas bien dans ma console, car :

import sys
>>> sys.stdout.encoding
'cp1252'

elle n'affiche pas en utf-8, mais en cp1252 (IDLE sour windows XP).

Mais y'a quand même un truc que je ne pige pas.
Je m'explique :
- Voici une chaine :

>>> s1 = "éléphant"
>>> s1
'\xe9l\xe9phant'

- Comme expliqué plus haut, elle est encodée en cp1252.
- Pour la décoder, il faut préciser à python l'encodage :

>>> s1u = s1.decode('cp1252')
>>> s1u
u'\xe9l\xe9phant'

- le "u" devant les drôles de signes veut dire que cette chaine est maintenant "unicodée" (c'est ça ?)
- Maintenant, voici une autre chaine :

>>> s2 = u"éléphant"
>>> s2
u'\xe9l\xe9phant'
>>> s1u == s2
True

s1u et s2 contiennent donc la même chose. Ce qui veut donc dire que python a directement désencodé la chaine u"éléphant" en unicode. Comment a-t-il réussi ça sans connaitre le codage utilisé (puisque je ne l'indique pas pour s2) ? Ca veut donc dire qu'il le sait ? Comment ?
- J'en conclue donc que :
* lorsqu'on fabrique une chaine dans un script python, il suffit de mettre "u" devant, et c'est bon
* lorqu'on veut importer ou exporter des chaines de caractères, là, il faut connaitre leurs encodage et utiliser les méthodes ".decode('codage')" et ".encode('codage')".

J'ai bon ? J'aimerais bien comprendre ça avant d'aller plus loin...

bipede · Le 22/08/2007, à 15:33

Je me suis un peu mélangé dans mes explications
Bon, on recommence :

La console:

Chaque système possède son encodage par défaut pour les sorties standard stdout de type console.

Ainsi, quand fait un print d'une chaine de caractère de type str(), celle-ci est encodée différemment selon qu'on se trouve sous ubuntu ('utf-8') ou sous windows ('cp850').
Pour pouvoir afficher à l'aide de print une chaine de caractère encodée différemment, il faut d'abord la transformer en chaine unicode à l'aide de la fonction decode() et le bon codec.

exemple:

Sous Windows, on a dans la variable s1 une chaîne "éléphant" encodée en utf-8
si on fait un print de s1 on obtient:

éléphant

La raison en est que la sortie standard traduit en "cp850"
Pour pouvoir visualiser correctement la chaîne de caractère il faut d'abord la tranformer en chaine unicode en utilisant le codec de l'encodage initial.

s1 = s1.decode('utf-8')

si on regarde le contenu en faisant s1 (sans print) on obtient bien une chaine unicode

u'\xe9l\xe9phant'

On peut la visualiser avec un print:

>>> print s1
éléphant

On peut même, à partir de ce moment la ré-encoder en 'cp850' qui est le codec de base pour la console windows pour la visualiser sans passer par unicode:

>>> s1 = s1.encode('cp850')
>>> s1
'\x82l\x82phant'
>>> print s1
éléphant

Un script python dans un fichier

la ligne

# -*- coding: utf-8 -*-

permet d'indiquer à python quel est le charset à utiliser pour interpréter le code contenu dans le fichier.
En effet, python interprète par défaut en ASCII, et si des caractères accentués sont utilisées au sein des lignes de code, une erreur de compilation est générée.

Le fichier lui-même
Il peut être sauvegardé avec l'encodage que l'on veut, mais s'il est sauvegardé en utf-8, puis ouvert sous windows et re-sauvegardé en latin-1, les caractères accentués perdront leur formatage et le programme ne fonctionnera plus.
C'est pourquoi j'ai pris l'habitude de sauvegarder mes scripts avec le même encodage que celui indiqué à python dans la ligne de codage.

pépère · Le 22/08/2007, à 15:41

Merci pour tes explications très claires bipèdes.
C'est je pense ce que j'avais fini par comprendre.
Pourrais tu me confirmer que u"éléphant" et "éléphant".decode('cp1252')" donnent bien le même résultat, à savoir une chaine unicode identique (c'est ce que cela fait chez moi) ? Saurais tu pourquoi ?

NB : sous windows XP, avec l'éditeur IDLE, il semble que ce soit cp1252 et non cp850 (peu importe...)

bipede · Le 22/08/2007, à 15:59

Effectivement u"éléphant" et "éléphant".decode('cp1252') donnent le même résultat.
Quand tu saisis une chaîne dans IDLE (sans la faire précéder du 'u'), IDLE utilise son encodage standard stdin pour interpréter ta saisie (cp1252). Donc tu te retrouves avec un str() codé en cp1252. Si tu prends ce str() et le transforme en chaîne unicode à l'aide de l'instruction decode, et que tu utilises pour le faire, le charset initial cp1252, c'est comme si tu créais ta chaine avec le préfixe 'u'. Il est donc normal que tu obtiennes le même résultat.
Essayes donc de decoder ta chaîne avec un autre charset (utf-8 par exemple) et vois le résultat. La divergence viendra du fait que l'encodage et le décodage n'auront pas été réalisé avec le même charset.

Au fait, IDLE sous win utilise le charset cp1252, mais la console (fenêtre DOS) utilise cp850...

pépère · Le 22/08/2007, à 18:29

Bon, bah merci bipede, je pense qu'avec ces bases, je pourrais me débrouiller par la suite !

J'apprend python grâce au fameux livre "apprenez à programmer avec python". Malheureusement, ce problème d'encodage (en dehors du pseudo commentaire d'entête des scripts) n'est soulevé que dans une petite note en bas de page... Du coup, la première fois qu'on fabrique une chaine de caractères avec autre chose que des caractères pris en charge par ASCII, on est un peu surpris !

aleph · Le 22/08/2007, à 21:30

Les explications de bipede sont bonnes et correctes. Je vais ajouter quelques
commentaires en suivant le fil de la discussion.

>pépère
Comme tu as bien lu le lien que j'ai donné plusieurs fois, http://www.joelonsoftware.com/articles/Unicode.html, tu as compris qu'une chaîne de caractères (ou pour être précis ce qui va être une chaîne de caractères) est représentée par une suite de bits ou bytes. Cette suite de bytes n'a aucun sens en soi. Cette série de bytes pourrait représenter quelquechose de plus humain si on assigne à ces bytes un "code". C'est ce que l'on appelle encodage (en bon français on devrait dire codage).

UNE CHAINE DE CARACTERES / BYTES N'A UN SENS QUE SI L'ON CONNAIT SON ENCODAGE

COROLLAIRE: IL EST IMPOSSIBLE DE DETERMINER L'ENCODAGE D'UNE CHAINE DE CARACTERES.

Tout moteur qui traite des chaînes de caractères fonctionne selon la filière suivante:

flux d'entrée (1) --> moteur (2) --> flux de sortie (3) --> représentation humaine (4)

(1) : clavier, fichier, base de donnée, gui...
(2) : compilateur, interpréteur, traitements de texte, visualisateur html, ...
(3) : flux de sortie, des bytes.
(4) : fichier, affichage, imprimante, gui...

Les encodages de ces quatre étapes peuvent être différents. C'est à l'utilisateur de veiller à ce que tout soit compatible et fonctionne au mieux, puisque, comme il est dit plus haut - et je le répète -, il est impossible de déterminer l'encodage d'une chaîne de caractères.

Pour beaucoup de moteurs, les étapes (3) et (4) sont fusionnées en une seule, par ex. un visualisateur html comme FireFox.

Python permet de travailler distinctement au niveau de ces quatres étapes.

Quand on utilise Python, il faut bien distinguer deux choses distinctes:
a) sa capacité de travailler comme moteur (1) --> (4)
b) sa faculté de modifier les encodages des chaînes de caractères au niveau (2).

La difficulté de compréhension vient du fait que pour voir le travail de b), il faut utiliser a).

Python et son interpréteur interactif sont vraiment extraordinaires pour jouer et comprendre ce que sont les encodages, comme l'atteste les exemples vus dans cette discussion.

Commentaires additionnels

> Je crois que j'ai compris l'importance de spécifier l'encodage des chaines de caractères utilisés. J'essaie pour le moment de faire joujour avec les conversions...

Excellente idée. Utile non seulement avec Python, mais pour tout ce qui touche aux encodages, bases de données, document tex, html, ...).

> "Encodé correctement le texte sera affiché."

Oui, je l'ai écrit, mais il ne faut pas sortir ce bout de texte de son contexte.

> Ton texte est encodé avec l'encodage par défaut de ton système (visiblement c'est de l'utf-8).

Juste, c'est l'étape (1).

> Si tu ne connais pas cet encodage par défaut, tu peux difficilement le décoder correctement pour le transformer en str.

Cf ma remarque initiale, un string (chaîne de caractères) sans aucune connaissance de son encodage n'a aucune valeur.
Exemple avec une console Python, IDLE sous Windows

>>> 'éléphant'.decode('cp1252')
u'\xe9l\xe9phant'
>>> 'éléphant'.decode('utf-8')

Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    'éléphant'.decode('utf-8')
  File "c:\python25\lib\encodings\utf_8.py", line 16, in decode
    return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-2: invalid data
>>>

La première commande fonctionne, la deuxième pas. C'est parce que je sais que sous IDLE (Windows) l'encodage est cp1252. La commande signifie "prends le string éléphant et decode le en utilisant cp1252 comme étant l'encodage d'éléphant"

> - A quoi sert de préciser dans l'entête que mon script est écrit en utf-8 (# -*- coding:Utf-8 -*-), puisqu'on doit indiquer l'encodage utilisé à chaque fois qu'on fabrique une chaine de caractères ?

C'est l'encodage dans (2). Il est important de comprendre que c'est l'encodage que le moteur va utiliser (ici Python) pour faire son travail. Cet encodage n'est pas nécessairement celui du fichier qui contient cette information. Il se trouve que la forme de cette information, une expression régulière précise, est aussi utilisée par de nombreux éditeurs.

(bipede: Scite ne reconnait un fichier utf-8 qui si celui-ci contient un BOM, autrement il interprète le fichier comme étant une simple suite de bytes, cad comme de l'iso-8859-1)

> la première de tes commandes encode u"éléphant" en utf-8. Mais "éléphant" est codé en quoi à l'origine ? Comment python arrive-t-il à le "traduire" en utf-8 alors qu'on indique pas l'encodage ?
...avec...
>>> s1 = u"éléphant".encode('utf-8') #encodage en utf-8

C'est expliqué correctement plus bas dans la discussion. Plus précisément, c'est le toolkit grahique, ce qui a permis à l'utilisateur d'entrer un string (Tk dans le cas d'IDLE) qui informe Python de l'encodage. Si un jour tu utilises wxPython, tu apprendras que wxPython existe sous deux formes une ANSI et une unicode. Autrement dit un forme qui revoie au moteur Python des infos sous forme ANSI et une forme qui renvoie des unicodes nativement. Malgré ceci, cela n'empêche pas le programmeur de pouvoir travailler en str ou en unicode dans les deux cas. Il veillera à encoder/décoder les strings correctement. Evidemment, on ne peut afficher dans la version ANSI des unicodes incompatilbles. C'est l'étape (4).

>
>>> s1 = u"éléphant".encode('utf-8') #encodage en utf-8
>>> print s1
éléphant

Tu as simulé avec une console Python exactement ce que l'on voit sur le web. Les pages mal encodées. L'encodage réel de la page html (étape (1) ne correspond pas à l'encodage déclaré qui doit être utilisé dans l'étape (3)(4).

> - j'ai l'impression qu'il n'y a pas de moyen de dire à python dans un programme d'utiliser et d'afficher le charset et l'encodage par défaut du système où il tourne. Me trompe-je ?

Au contraire, Python est d'une souplesse extraordinaire. Je pense que tu l'a bien compris.
Ce que Python ne peut pas faire, étape (2), c'est de deviner quel est l'encodage d'entrée (1)
et de savoir quel est l'encodage qu'il faudra utiliser pour les étapes (3) ou (4).Ici, on retombe dans la discussion du début, un string n'a de sens que si l'on connaît son encodage. Ceci n'est d'ailleurs pas propre à Python.

> je me suis un peu mélangé dans mes explications roll
Bon, on recommence

Bon travail qui va bien dans le sens de la filière proposée.

> Le fichier lui-même
Il peut être sauvegardé avec l'encodage que l'on veut, mais s'il est sauvegardé en utf-8, puis ouvert sous windows et re-sauvegardé en latin-1, les caractères accentués perdront leur formatage et le programme ne fonctionnera plus.
C'est pourquoi j'ai pris l'habitude de sauvegarder mes scripts avec le même encodage que celui indiqué à python dans la ligne de codage.

C'est une excellente remarque. Qui n'est d'ailleurs pas seulement vraie pour Python, mais aussi pour tous les fichiers dits textes, texte brut, page html, documents tex, scripts Python, Ruby...

On adapte ses outils de travail à l'encodage du fichier texte, on ne fait pas l'inverse. Tous les bons outils sous toutes les plateformes permettent de le faire. Même Notepad le fait, en plus il peut même reconnaître le BOM, ce que bien des outils sous Linux ne font pas.

Modifier les fichiers à coup d'iconv est une absurdité. Surtout quand on ne comprend pas ce que l'on fait.

Il faut bien comprendre que si tu échanges (ou récupères des fichiers à droite et à gauche), tu ne va pas passer ton temps à les décoder et réencoder pour les renvoyer à leur destinataire que celui-ci soit un Vietnamien ou un autre OS.

> ...charset unicode...
En principe on dit unicode tout court. u'éléphant' est un unicode. Il n'y aucune info sur son encodage.
Une chaîne comme 'éléphant' est un objet de type "str". On l'appelle souvent un byte string.

> ...numéro unicode...
On ne parle pas de numéro. Chaque élément de la table est un "code point". \u0061 (hex) est le code point de "a".

Python possède un excellent module, unicodedata, voir doc. concernant la base de donnée unicode.
Par exemple, il est possible d'obtenir le nom de chaque "code point"

>>> import unicodedata as ud
>>> ud.name(u'a')
'LATIN SMALL LETTER A'
>>> ud.name(u'Ü')
'LATIN CAPITAL LETTER U WITH DIAERESIS'
>>>

Il n'y a que les unicodes qui ont un encodage. Les ascii, iso-8859-1 et autres où chaque caractère est représenté par un byte unique sont plutôt des tabelles de correspondance, code point -> char.
Parler d'encodage est abusif, mais bon c'est l'usage.

En espérant avoir apporté un peu d'eau au moulin.

pépère · Le 23/08/2007, à 07:36

Oui Aleph ! Que d'eau, que d'eau !
J'ai vu que tu avais participé à pas mal de posts sur ce sujet, et qu'il a l'air de te tenir à coeur... Mais parfois, on a besoin d'être un peu assisté pour être sûr qu'on ne fait pas fausse route. J'avais lu l'article que tu as indiqué quand je suis tombé sur le post de Shuriken (je le jure ! ). J'ai suivi tes explications, mais le déclic ne s'est pas fait à ce moment là (à ma défense, un des liens que tu indiques ne s'ouvre pas chez moi : http://www.jorendorff.com/articles/unicode/python.html)
En fait, auparavant, j'avais bien sûr déjà rencontré cette thématique en LaTeX et en html (ça fait un peu prétentieux, je n'en connais que quelques rudiments ). Mais dans ces deux langages, il suffit de préciser en entête l'encodage utilisé pour son fichier source, et ça marche ! Et on se dit alors que tout est si simple...
Mais avec python, on doit passer une étape supplémentaire. Il faut apprendre la différence entre le charset et l'encodage. Il faut penser à gérer les deux dans son code, et ça trouble au début.

Ce que je conclu de tout ça : créer/convertir en unicode toutes les chaines de caractères avant de les manipuler, puis convertir dans le codage qui va être affiché lorsque on "fait sortir" le résultat des manipulations. On évite alors pleins de problèmes.

J'ai bon ?

J'ai une petite dernière remarque sur ça :

> la première de tes commandes encode u"éléphant" en utf-8. Mais "éléphant" est codé en quoi à l'origine ? Comment python arrive-t-il à le "traduire" en utf-8 alors qu'on indique pas l'encodage ?
...avec...
>>> s1 = u"éléphant".encode('utf-8') #encodage en utf-8
C'est expliqué correctement plus bas dans la discussion. Plus précisément, c'est le toolkit grahique, ce qui a permis à l'utilisateur d'entrer un string (Tk dans le cas d'IDLE) qui informe Python de l'encodage. Si un jour tu utilises wxPython, tu apprendras que wxPython existe sous deux formes une ANSI et une unicode. Autrement dit un forme qui revoie au moteur Python des infos sous forme ANSI et une forme qui renvoie des unicodes nativement. Malgré ceci, cela n'empêche pas le programmeur de pouvoir travailler en str ou en unicode dans les deux cas. Il veillera à encoder/décoder les strings correctement. Evidemment, on ne peut afficher dans la version ANSI des unicodes incompatilbles. C'est l'étape (4).

Cela veut dire que :
- quand je tape directement dans IDLE, "éléphant" de u"éléphant" est codé en 'cp1252'. Python le sait car c'est IDLE qui le lui dit.
- lorsque je créé un script avec un éditeur de texte codant en utf-8, "éléphant" est codé en utf-8. Lors du lancement du script (commande "python monscript.py"), Python saura comment le transformer en unicode grâce à l'entête du script qui précise l'utf-8 (si je l'oublie, ça ne marchera pas).
- Mais quand je copie-colle u"éléphant" de mon script (utf-8) à la fenêtre IDLE (qui utilise cp1252), que devient l'encodage ? Ce bout de chaine transférée de l'éditeur à IDLE reste-t-elle en utf-8 ou est-elle converti en cp1252 quelque part sur le trajet ? (j'espère que ma question est claire).

Voilà, je vous remercie tout les deux sincèrements pour vos explications très claires, et pour votre patience.

Edit : j'aimerais bien acheter un livre "de référence" un peu plus complet que "Apprendre à programmer avec python", où je pourrais aller voir si j'ai besoin d'informations complémentaires sur un sujet. Vous avez un conseil ? Voilà ce que j'ai trouvé :
- Programmation python : http://www.amazon.fr/Programmation-Python-Tarek-Ziad%C3%A9/dp/2212116772/ref=pd_bbs_3/403-9080392-7401258?ie=UTF8&s=books&qid=1187851855&sr=8-3
- Au coeur de python : http://www.amazon.fr/Au-coeur-Python-Notions-fondamentales/dp/2744021482/ref=pd_bbs_5/403-9080392-7401258?ie=UTF8&s=books&qid=1187851855&sr=8-5
- Python en concentré : http://www.amazon.fr/Python-en-concentr%C3%A9-Alex-Martelli/dp/284177452X/ref=pd_bbs_4/403-9080392-7401258?ie=UTF8&s=books&qid=1187851855&sr=8-4
- Python par l'exemple : http://www.amazon.fr/Python-par-lexemple-Alex-Martelli/dp/2841773795/ref=pd_bbs_7/403-9080392-7401258?ie=UTF8&s=books&qid=1187851855&sr=8-7

Les deux premiers ont l'air d'être didactique (donc peut être répétitif avec le livre que j'ai déjà ?), et les deux suivants on l'air d'être très complet... A votre avis, lequel complètera le mieux "Apprendre à prgrammer avec python" de Gérard Swinnen ?

Dernière modification par pépère (Le 23/08/2007, à 07:54)

aleph · Le 23/08/2007, à 09:48

Le lien est correct. Moi aussi ce matin, je n'arrive pas à atteindre la page.

Pour la doc, la seule et unique documentation officielle et son tutoriel que tout utilisateur Windows ou OSX reçoit en installant Python reste à mes yeux la meilleure.

Pour parfaire ses connaissance dans les encodages, wikipedia est très bien, je conseillerais plutôt la version en anglais.

> Mais quand je copie-colle u"éléphant" de mon script (utf-8) à la fenêtre IDLE (qui utilise cp1252), que devient l'encodage ? Ce bout de chaine transférée de l'éditeur à IDLE reste-t-elle en utf-8 ou est-elle converti en cp1252 quelque part sur le trajet ? (j'espère que ma question est claire).

Bien vu ! C'est une remarque très intéressante. C'est aux applications émettrices et réceptrices de s'en occuper correctement, que ce soit couper ou coller. C'est à ce genre de détails que l'on peut tester la qualité d'une application et c'est souvent ici que l'on voit la différence en le "progammeur du dimanche" et le pro. C'est toujours un très gros travail qui demande beaucoup de code et alourdi une application. Si en plus, tu comprends qu'une application est basée sur le gui qui sert à la créer (win32, gtk, qt), tu vois les problèmes...

Le même raisonnement s'applique à bien d'autres aspects.

Evidemment, reste à savoir si le jeu en vaut la chandelle. Pour des applications comme Word, OOo ou FireFox, la réponse est évidente. Pour de petites applications, peut-être pas, il n'en demeure pas moins que le minimum se doit d'être correct.

Pour les encodages, méfie toi comme la peste de ce que l'on trouve sur le web. Beaucoup de recettes et peu de compréhension. La palme revient certainement aux Américains qui confondent joyeusement ascii et unicode/utf-8, la différence étant invisible mais présente.

Comme je l'ai lu quelque part, "unicode c'est bien, malheureusement les Américains l'on transformé en ascii2"

Il est aussi faux de croire que tout ce qui tourne sous Linux/Ubuntu "parle" unicode.

Essaie ceci:

>>> s = abs.__doc__
>>> s
abs(number) -> number

Return the absolute value of the argument.
>>> isinstance(s, str)
True
>>> isinstance(s, unicode)
False

Fait sous Windows, mais je suis certain que certains "docstrings" Python sont de type "str".

Si j'ai le temps et pas trop la flegme, je soumettrai deux trois petits trucs que l'on peut faire avec une console Python.

pépère · Le 23/08/2007, à 13:40

Bon, bah je crois que je vais continuer d'avancer doucement dans mon apprentissage.
--> [résolu] et merci à tous les deux !

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 22/08/2007, à 09:29

[résolu] python et encodage des caractères.

#2 Le 22/08/2007, à 10:56

Re : [résolu] python et encodage des caractères.

#3 Le 22/08/2007, à 13:00

Re : [résolu] python et encodage des caractères.

#4 Le 22/08/2007, à 15:06

Re : [résolu] python et encodage des caractères.

#5 Le 22/08/2007, à 15:33

Re : [résolu] python et encodage des caractères.

#6 Le 22/08/2007, à 15:41

Re : [résolu] python et encodage des caractères.

#7 Le 22/08/2007, à 15:59

Re : [résolu] python et encodage des caractères.

#8 Le 22/08/2007, à 18:29

Re : [résolu] python et encodage des caractères.

#9 Le 22/08/2007, à 21:30

Re : [résolu] python et encodage des caractères.

#10 Le 23/08/2007, à 07:36

Re : [résolu] python et encodage des caractères.

#11 Le 23/08/2007, à 09:48

Re : [résolu] python et encodage des caractères.

#12 Le 23/08/2007, à 13:40

Re : [résolu] python et encodage des caractères.

Pied de page des forums