Installer un module Python

Bonjour,

Il est probable qu'un des fichiers (lequel ?) contienne des identifiants ou chaînes de caractères codés en ISO 8859-1, sans que la déclaration de codage correspondante (“encoding declaration”) n'ait été placée dans les premières lignes du fichier.

0xE9 est LATIN SMALL LETTER E WITH ACUTE en ISO 8859-1, bref : un 'é'. Il faut sans doute identifier le ou les fichiers concernés et ajouter une déclaration de codage adéquate. Par exemple, pour UTF-8, le fichier peut commencer ainsi :

#! /usr/bin/env python3
# -*- coding: utf-8 -*-

(ne pas mettre la première ligne pour les modules importés mais seulement pour ceux destinés à être lancés directement comme scripts). UTF-8 est le codage par défaut depuis Python 3. Voir ici pour les noms correspondant à ISO 8859-1 (ou ISO 8859-15, voire d'autres codages : la seule valeur 0xE9 ne permet pas d'être certain du codage utilisé).

A priori, l'erreur devrait se produire chez tous les utilisateurs de ce module sous Python 3, comme tu le suggères. Autrement, youtube-dl fonctionne bien en ligne de commande.

La déclaration de codage n’est pas nécessaire en Python 3, c’est de l’utf-8 par défaut.

youtube-dl est écrit en Python et fonctionne très bien.

@Alban_

Dans ton premier message, tu as donné ce message d'erreur :

'utf-8' codec can't decode byte 0xe9 in position 308: invalid continuation byte

Cela donne une position très précise dans un fichier, mais lequel ? Sérieusement, ça n'était pas écrit au-dessus ?

Edit : ce type de message me rappelle des choses, maintenant. Plus qu'à un problème de déclaration de codage du fichier Python, cela est à mon avis dû à un authentique bug du code de ce pytube, qui ne fait sans doute pas le .decode() nécessaire avec codage explicite pour convertir un objet 'bytes' en chaîne de caractères, ou qui le fait avec un codage inadapté à la donnée d'entrée (voir exemple simple reproductible dans mon message suivant). Il y a peut-être un « é » dans les métadonnées de ta vidéo (titre, etc.), ce qui ferait sortir du bois le bug en question. Je mets donc entre parenthèses le paragraphe suivant.

(J'ai regardé la branche master du dépôt que tu as indiqué toujours dans ton premier message. Il y a de nombreux caractères non ASCII, mais cela semble être de l'UTF-8... sauf si j'en ai manqué un. D'où l'importance de savoir de quel fichier Python se plaignait.)

Mais on est d'accord que c'est purement déclaratif ? Et quelqu'un qui écrirait cela sans se poser de question en début de chaque script qu'il produit est plus gênant que quelqu'un qui ne l'écrirait jamais ?

Que veux-tu dire par « c'est purement déclaratif » ? Que ça ne change pas le fonctionnement du programme ? Si. Le programme suivant :

#! /usr/bin/env python3
# -*- coding: utf-8 -*-

print(ord("é"[0]))

correctement sauvé en UTF-8, affiche 233 (i.e., 0xE9). Si l'on se contente alors de changer 'utf-8' en 'latin-1' et que l'éditeur de texte n'essaie pas d'être plus malin que l'utilisateur, alors le programme affiche 195. En effet, le « é » (LATIN SMALL LETTER E WITH ACUTE) est U+00E9, qui est dans la plage U+0080­ à U+07FF. Ces codes-là sont représentables avec 11 bits et les 11 bits de poids faible de l'écriture binaire de 0xE9 sont 000 1110 1001. Ceci est découpé en deux tranches ($5 + 6 = 11$) comme indiqué ici, soit 00011 et 101001. La première tranche devient le xxxxx du premier octet noté 110xxxxx dans le lien que je viens de donner, ce qui donne 11000011 en binaire, c'est-à-dire 195 en écriture décimale.

(Le deuxième et dernier octet du codage UTF-8 de LATIN SMALL LETTER E WITH ACUTE est 10xxxxxx avec xxxxxx = 101001, autrement dit 10101001, soit 169 en écriture décimale.)

Donc, quand on écrit un programme ou un fichier texte quelconque, le mieux est de se renseigner sur son éditeur de texte pour savoir dans quel codage il enregistre les fichiers. UTF-8 est presque toujours préférable de nos jours.

Wilfrid a écrit:

Python doit être compilé en JavaScript

Il vaut mieux être aveugle...

@Wilfrid

Et donc ? Pas besoin de JavaScript pour faire tourner youtube-dl.

@Alban_

Voici un exemple simple de bug produisant le message d'erreur que tu as cité dans ton premier post. Le programme « modélise » un code qui reçoit la chaine de caractères "éA" codée en ISO 8859-1, donc sous la forme d'un objet 'bytes'. Il tente de la convertir en objet 'str', i.e. de la décoder, mais pour cela demande implicitement à Python de l'interpréter comme de l'UTF-8, ce qui est impossible :

#! /usr/bin/env python3

print(b'\xe9A'.decode())

=>

Traceback (most recent call last):
  File "/tmp/./essai.py", line 3, in <module>
    print(b'\xe9A'.decode())
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe9 in position 0: invalid continuation byte

Si la donnée d'entrée est dans un codage compatible avec UTF-8, comme c'est le cas d'ASCII, alors le bug passe inaperçu :

#! /usr/bin/env python3

print(b'AA'.decode())

=>

AA

C'est exactement pour ça qu'il est très important que les programmeurs comprennent le concept de codage de caractères et précisent explicitement le codage partout où il y a du texte. Sinon, on a des bugs cachés qui apparaissent au gré des données, et toute automatisation devient impossible, ou foireuse et pure perte de temps (heuristiques pour détecter le codage...).

@Alban_

Ta suggestion n'est pas stupide, ce pourrait effectivement être pip... ou bien le setup.py de pytube exécuté par setuptools par l'intermédiaire de pip. Cela dit, après un coup d'œil rapide sur le setup.py en question, je ne vois pas d'où vient ce 0xe9. Celui qui afffiche le message d'erreur a vraiment fait un travail de cochon.

Je ne vais pas installer pytube pour investiguer plus (connais pas et pas que ça à faire, désolé). Ce que je peux affirmer en revanche, c'est que le script Python 3 suivant télécharge ta vidéo sans problème (il s'agit de Mega Man, pas de Mario !) :

import youtube_dl

ydl_opts = {}
with youtube_dl.YoutubeDL(ydl_opts) as ydl:
    ydl.download(['https://www.youtube.com/watch?v=NqC_1GuY3dw'])

Il utilise youtube-dl, comme tu t'en seras douté. J'ai simplement pris le code ici, retiré une ligne inutile sous Python 3 et remplacé l'adresse par celle que tu as donnée.

Pour ce qui est de reproduire mon petit test ici, dans le second cas, il ne faut surtout pas changer le codage du fichier — seulement sa déclaration de codage. En effet, il s'agit de montrer que la déclaration de codage a un effet bien réel sur le fonctionnement d'un programme Python. L'expérience n'est donc valable que « toutes choses égales par ailleurs ». Si on fait ce que je dis, la chaîne de caractères a pour longueur 2 lorsque la déclaration de codage stipule latin-1, et le programme affiche le code Unicode de son premier caractère, dont j'ai expliqué l'origine.

Tout est bien qui finit bien. ;-)

J'attache mon fichier de test obtenu en sauvant ceci en UTF-8 (pas avec Emacs : il fait le malin et sauve systématiquement en ISO 8859-1 à cause de la déclaration de codage) :

#! /usr/bin/env python3
# -*- coding: latin-1 -*-

print(ord("é"[0]))

En raison de cette déclaration de codage, Python va voir ça :

#! /usr/bin/env python3
# -*- coding: latin-1 -*-

print(ord("é"[0]))

(et c'est aussi ce qu'affiche Emacs si on ouvre le fichier, car il comprend ces déclarations de codage). Voilà pourquoi la chaîne de caractères est dans ce cas composée de 2 caractères dont le premier est Ã, c'est-à-dire U+00C3, i.e. 195 en décimal. Donc le programme affiche 195. Tu peux exécuter le fichier attaché dans un terminal pour vérifier.