merci merci :-)

sauf que la video est bloquée pour des raisons de droit d’auteur, mais le reste ça va)

Quand on a voulu faire le split octets / texte en Python 2, on s’est hurté à un problème: on avait déjà donné le nom str à quelque chose qui n’était PAS du texte selon la nouvelle API.

Donc a on fait str / unicode, et str est le nom resté pour représenter … ce qui n’est pas du texte.

Du coup tout le monde continue de se gourer en Python 2, voulant manipuler du texte, mais manipulant des bytes sans comprendre la plupart du temps.

En Python 3, on a corrigé ça, et str() représente / converti bien du texte, tandis que bytes() represente / converti bien des bytes.

Le comportement de Python est donc logique, et même sain, mais pour des raisons de compatibilité, on ne peut pas avoir une sémantique clair en Python 2. Il est en effet, hors de question de casser python 2.

La première, c’est pour remercier. Ces dernières années j’ai relu cet article un certain et il m’a beaucoup aidé à comprendre comment fonctionne l’encoding en Python, qui soyons clair, est passablement merdique… Donc voilà, merci beaucoup pour ces infos précieuses.

Deuxièmement, pour émettre des réserves sur un principe énoncé ici et que j’ai longtemps essayé d’appliquer sans succès, à savoir préfixer toutes ses chaînes avec u”machin” pour que toutes les chaînes aient le type unicode. De mon expérience, faire ça débouche presque obligatoirement sur de nouveaux plantages d’encoding. Pour deux raisons, mais qui au final reviennent à la même :

1) le type str est différent du type unicode et par conséquent, une fonction qui attend un type str peut avoir un comportement différent si on lui transmet une variable de type unicode voire (et c’est le cas la plupart du temps) planter, souvent pour la raison en 2)

2) la fonction str() de python (en version 2.7 du moins) est de la merde et plantera sur toute variable de type unicode contenant un caractère non-ascii, bien que d’après sa doc officielle “return a string containing a nicely printable representation of an object.”. Peut importe donc que tu te sois fais chier à gentiment décoder ta chaîne avec le bon codec, python s’en branle et essaie de la réencoder en ascii à l’appel de str()…

Or, en revanche, l’appel de str() sur une chaîne encodée (str) contenant des caractères non-ascii ne plante pas. C’est un comportement qu’on peut critiquer, mais on peut aussi le voir autrement en estimant que python délègue simplement la responsabilité d’interpréter les caractères au terminal de sortie, SI terminal de sortie il y a. Et justement, dans de nombreux cas, dans le cadre d’utilisation de la chaîne au sein du programme python, on utilise de nombreuses chaînes “transitoires” qui n’ont pas vocation à être imprimées (par python du moins) : clés de dictionnaire, requêtes SQL, etc. Il n’y a donc strictement aucun intérêt à les décoder.

Pour en revenir au comportement de str(), pour moi c’est une énorme aberration, surtout que par ailleurs, on a le même problème dans l’autre sens : un appel de unicode() sur une chaîne encodée (str donc) contenant des caractères non-ascii va planter. La conséquence misérable, c’est qu’il n’existe aucune fonction universelle en python permettant d’extraire la valeur imprimable d’une variable quel que soit son type, alors que c’est ce que str() devrait faire ! Dès qu’on construit une fonction de type logger() par exemple qui va faire du str() sur toutes les variables qu’on lui envoit (peut importe leur type), on va être obligé de vérifier leur type avant JUSTE pour gérer le cas des chaînes décodées, ce qui soyons clair, est complètement débile….

Je suis ouvert bien sûr aux remarques et critiques (si vous avez eu le courage de lire mon pavé :P)

C’est une spécificité de Python : si l’encoding du fichier est différent de l’encoding par défaut du langage, il faut le déclarer sinon le programme plantera à la première conversion.

J’ai un comportement curieux d’un ETL incluant des scripts python

-- coding: utf-8 --

print(type(unicode("Début Logging")))

print(type(u"Début logging"))

renvoient une erreur ‘utf8’ codec can’t decode byte 0xe9

Et effectivement si je fais un print d’un chardet.detect de la chaîne de caractère (non unicode) dans ce logiciel il retourne ‘windows-1252’ (ou Latin-2 selon les accents que j’utilise, comme tu le dis bien la détection n’est pas une science exacte), du coup j’ai l’impression que python en lisant u”Debut Logging” tente de faire un “Début Logging”.decode(‘utf-8’) alors que la chaine d’entrée est resté dans un autre encodage.

Est-il possible que ma déclaration # coding : utf8 induise en erreur l’interpréteur python ? J’avais l’impression que ce n’était qu’une consigne pour les éditeurs de texte…

Confirmez vous ? Une solution ?

Je veux modifier des csv en Windows-1252 ou UTF-8 (je reçois l’info en paramètre).

Par ex. j’ai en entrée des colonnes du genre “Prénom Nom” et des valeurs du genre ‘Rémi Dufrêne’ et je veux en sortie ‘PRENOM’,’NOM’ et ‘Rémi’,’Dufrêne’

La doc Python https://docs.python.org/2/library/csv.html dit que le module csv ne gère pas l’unicode et explique des trucs en 13.1.5 que je ne comprends pas.

En tout cas merci(s).