J’ai envie de passer à autre chose. Max ne s’en occupe plus depuis longtemps. Du coup je mets sametmax.com en berne. Vu le rythme de publication de 2019, ça ne fera pas une grosse différence de toute façon.
Évidemment, il restera en ligne, avec tout son contenu. 0bin.net aussi. Rappelez-vous que vous pouvez télécharger tout le blog pour le consulter hors ligne avec un petit:
wget -m -k -p -c -E http://sametmax.com
Max, pour le moment, veut bien maintenir à flot le multiboards et a même fait un peu de modération sur indexerror.net donc pour le moment, les services restent up.
J’avais déjà laissé tomber le reddit et le mastodont, mais le compte Twitter restait très actif. J’ai fait une demande de twitter pour télécharger tous les tweets pour avoir un historique. Je pense le mettre en lecture seule.
Ca a été un plaisir d’écrire les plus de 1000 articles de ce blog, avec la participation d’auteurs invités en prime, et les commentaires super sympas. Il y en a presque autant de pas publié, dont certains articles invités que je fais trainé depuis super longtemps. Désolé !
Même si Max n’a pas beaucoup écrit ces dernières années, c’est un pote en or et j’ai de la chance de l’avoir à mes côtés au quotidien. C’est vraiment hilarant d’aller à une conférence ou chez un client et d’entendre parler de nous: “tu connais sametmax ? – oui, très bon blog :) :) :)”.
Si j’avais su, j’aurais écrit cet article il y a 5 ans. Je pense que tellement de monde aurait évité des heures de frustration. Mais ça prend du temps de réaliser que des choses qui vous paraissent simples sont des obstacles pour d’autres.
Mieux vaut tard que jamais j’imagine.
Dans cet article, on va voir comment lancer python depuis la ligne de commande, ainsi que les commandes qui lui sont liées: pip, venv, etc.
Sous Windows
Vous avez installé Python, c’est certain. Vous lisez votre premier tuto, qui vous dit de lancer cmd.exe, et de taper python, mais impossible de le faire marcher. Des messages du genre ‘python’ is not recognized as an internal or external command apparaissent. Ou alors le mauvais Python se lance.
Déjà, premièrement, désinstallez Python, et réinstallez-le (en utilisant l’installeur officiel si possible), mais sur la toute première fenêtre de l’installeur, vérifiez bien que la case “Add Python to PATH” (ou son équivalent français) qui est tout en bas est cochée. Sans cela, le dossier d’installation de Python ne sera pas trouvable par le shell au moment de taper la commande. Je sais, ça devrait être coché par défaut. J’ai signalé ça plusieurs fois sur la mailing-list, et ils n’en ont rien à foutre.
Le clitoris de l’installation de Python
Alternativement, si vous ne voulez pas désinstaller Python, ou si vous n’utilisez pas l’installeur de Python standard, cherchez le dossier où vous avez installé python. C’est un dossier qui doit contenir python.exe et un dossier appelé Scripts. Très souvent on le trouve à C:\users\[votre nom d'utilisateur]\Local Settings\Application Data\Programs\Python\Python36. Ajoutez ce chemin dans le sys PATH, ainsi le chemin vers le sous-dossier Scripts.
Redémarrer votre console. Vous devriez au moins pouvoir taper python -v.
Maintenant, sachez que vous ne devriez pas taper la commande python.
Whaaaaaaaaaaaaat ?
Vous entends-je me hurler suavement à l’oreille.
Non. Sous Windows, vous devriez utiliser la commande py -X.Y. La commande py permet en effet de spécifier la version de Python à lancer. Par exemple py -2.7 pour lancer Python 2.7, ou py -3.6 pour lancer Python 3.6, s’ils sont installés sur la machine, bien entendu.
Pourquoi utiliser la commande py ? Et bien parce que sinon, python lancera le premier python.exe qu’il trouve. Si vous avez plusieurs versions de Python installées sur votre machine, ce qui est souvent le cas sur les machines de dev, des fois à son insu, vous allez avoir des problèmes.
En fait, quand vous lisez un tutoriel sur Python, si vous lisez quelque part “tapez python”, remplacez-le mentalement par “tapez py -X.Y”. La commande marche strictement pareil que la commande python traditionnelle. Elle prend les mêmes arguments, et lance le shell de la même façon.
Aussi, rien à voir, mais n’utilisez pas les terminaux de cmd.exe ou powershell.exe. Ils sont à chier. Prenez le temps de télécharger cmder, et si vous le pouvez, faites le cmder.exe /REGISTER ALL en admin tant que vous y êtes.
Aussi petite astuce bien pratique: si vous maintenez shift et que vous faites un clic droit dans l’explorateur de fichier ou sur le bureau, un menu contextuel différent de celui habituel s’ouvre. Il contient des actions fort utiles:
“Ouvrir fenêtre de commande ici”, qui vous ouvrira la console, immédiatement dans le bon dossier.
“Copier en tant que chemin d’accès”, qui vous permettra de mettre le chemin de n’importe quel fichier dans le presse-papier.
Sous Unix (Max, Linux, etc)
N’utilisez pas la commande python, mais utilisez une commande suffixée pythonX.Y. Par exemple, pour lancer Python 2.7, tapez python2.7, ou pour lancer Python 3.6, tapez python3.6.
En fait, quand vous lisez un tutoriel sur Python, si vous lisez quelque part “tapez python”, remplacez-le mentalement par “tapez pythonX.Y”. La commande marche strictement pareil que la commande python traditionnelle. Elle prend les mêmes arguments, et lance le shell de la même façon, mais comme on a souvent plusieurs versions de Python installées sur une machine (sans parfois même sans rendre compte), c’est important de le faire.
Pour les linuxiens seulement
Pip et virtualenv sont fournis quand on installe Python sous Mac et Windows, mais souvent pas sous Linux ! Assurez-vous de toujours les installer avec votre gestionnaire de paquet, et ce pour chaque version de Python que vous avez.
Exemple: yum install python3.6-pip ou apt install python3.6-venv.
Tous OS confondus
Quand vous utilisez une commande écrite en Python, mettez python -m devant. C’est un cheat code.
N’appelez-pas pip, mais python -m pip.
N’appelez-pas venv, mais python -m venv.
N’appelez-pas black, mais python -m black.
Si vous lisez dans un tutoriel “tapez pip install”, remplacez-le mentalement par “tapez python -m pip install”.
-m ne marche pas avec toutes les commandes (python -m jupyter console a un bug, snif) car cela suppose que le développeur de la commande y a pensé, mais c’est le cas de la plupart des outils modernes.
Or -m va vous éviter tout un tas de problème de PATH, de droits et de version de Python.
Donc, si on combine tous les conseils, n’utilisez pas pip, mais py -3.6 -m pip ou python3.6 -m pip.
Je sais, c’est plus long a taper, mais ça va bien vous aider.
pip install
Certains outils doivent s’installer en global. On voit souvent des conseils comme faire un sudo pip install ou un sudo easy_install. C’est mal. Ceci va pourrir les paquets système de Python, et peut avoir des conséquences indésirables. Notez que parfois, rien ne marche, et je le fais quand même du coup.
Mais la plupart du temps, ce qu’il vous faut, c’est --user, suivi de -m. Par exemple, ne faites pas:
sudo pip install black
black mon_fichier.py
Mais faites:
python3.6 -m pip install black --user
python3.6 -m black mon_fichier.py
Notez le --user, ainsi que les deux usages de -m.
Ceci va installer black localement, pas au niveau du système. On s’assure qu’on n’utilise bien Python3.6, à l’installation et à l’usage de black. Et comme on n’utilise -m, on a pas à se demander si la commande black est bien sur le PATH (pas besoin de trifouiller son .bashrc ou le sys PATH de Windows.)
Utilisez des virtualenvs. Abusez-en. Un virtualenv par projet. Un autre pour les tests rapidos. Un pour maman, un pour papa, et un pour le fun. Ils ne coûtent rien que quelques Mo sur votre disque dur, donc lâchez-vous.
Car dans un virtualenv, non seulement vous êtes isolés des autres installations de Python, mais en plus… tous les conseils ci-dessus ne sont plus nécessaires !
Vous pouvez taper juste python et juste pip, plus de py, plus de suffixes, plus de -m et --user. Joie !
Moralité: les rares fois où vous êtes hors virtualenv, suivez les conseils des autres parties de l’article (py -3.6 -m pip install --user ou python3.6 -m pip install --user). Et des que vous le pouvez, pouf, virtualenv, et tout va pour le mieux.
La 3.7 n’est non seulement pas aussi aisée à déployer, mais elle ne contient pas encore autant de correctifs, et surtout fige les mots clés async / await, créant des surprises. J’admets volontiers que breakpoint(), les dataclasses et asyncio.run() sont très tentants, mais je peux vivre sans.
Donc Python 3.6.
(P.S: django et numpy droppent le support de la 3.4)
Pour déployer, pex et nuikta
Quand j’ai scripts rapides mais pleins de dépendances , fini les virtualenvs et pip install en prod. Je package tout avec pex. Un fichier .pex est un format conçu par twitter l’équivalent d’un .war, que la présentation de Brian Wickman expliquera mieux que moi.
Mais en gros, en très gros, c’est un zip qui contient tout le virtualenv. On fait python mon_projet.pex et ça lance tout. Pas besoin de déploiement compliqué. scp, et c’est prêt. Je ne le recommande pas pour un gros projet web par contre. Mais pex rend le scripting Python merveilleux, et presque trop facile: plus besoin de s’interdire une dépendance par peur que le serveur ne l’a pas, ou par flemme. Du coup, même le script le plus simple à la puissance de feu de tout pypi, et ça m’a permis de faire des one-shots très complexes en deux coups de cuillères à pot.
Quand je dois livrer un programme chez un client qui ne soit pas Web, je compile tout avec nuitka. Je me fends même parfois d’un installeur nsis au besoin. Demander à autrui d’installer la VM est source de beaucoup de problèmes, et Python est un détail d’implémentation pour beaucoup d’utilisateurs de toute façon.
Gestion de projet: pew et setup.cfg
J’aime poetry, mais la compatibilité avec setuptools est importante à mes yeux. Tout l’écosystème supporte setuptools, tout est bien testé, c’est robuste et sans surprise. J’attendrais que poetry soit stable, testé, bien intégré et surporté. Évidemment, il faudra que pyproject.toml soit suffisamment mature également, et vu l’usage de sections custo pour tous les outils qui l’utilisent, on en est encore loin.
pew est très basique, mais il ne s’occupe que du virtualenv, laissant la gestion de mon projet à mes soins. Il est rapide, et sans chichi, de plus personne dans mon équipe n’a besoin de savoir que je l’utilise.
Après quelques essais, j’ai laissé tomber pipenv, qui a trop de problèmes, et dont l’auteur met des années avant d’entendre raison sur des choses essentielles, sur lesquelles il revient par ailleurs sans mine de repenti. Ça n’en retire rien à Kenneth Reth le mérite des ses travaux, mais j’ai des deadlines.
Outillage
À moins d’avoir été sourd et aveugle, vous avez du noter un certain engouement de la communauté pour black, que je vous ai déjà dis avoir adopté.
Les conséquences sont multiples sur la stack: j’ai viré flake8, et j’ai allégé de nombreuses règles ma configuration pylint, qui est du coup mon seul linter. Faudrait que je fasse un article dessus d’ailleurs.
Mypy étant maintenant stable et utilisable, je l’active par défaut. Ça ne veut pas dire que j’annote tout mon code. Parfois je n’annote rien. Parfois juste quelques fonctions. L’énorme avantage de mypy réside dans le fait que son utilisation est parfaitement progressive, et s’adapte à l’engagement et l’effort que vous voulez y mettre.date mypy est une des rares choses que j’upgrade à tout bout de champ, car chaque update amène une vraie qualité de vie en plus.
J’intègre tout ça dans mon éditeur, et en l’occurence VSCode rend l’opération très facile.
Pour le lanceur de tests, je reste sur pytest, pour des raisons déjà exposées. Honnêtement je ne connais pas de bonnes raisons de ne pas utiliser pytest. J’utilise faker pour générer des fausses données de test. Je n’arrive toujours pas à utiliser hypothesis. J’essaye, mais je n’arrive jamais à l’appliquer sur autre chose qu’un exemple joujou. J’espère y arriver un jour, car je suis certain que c’est excellent.
Pour lancer tout ce bordel, j’utilise tox, mais je ne l’utilise pas sur tous mes projets: seulement les gros avec certaines exigences.
Je n’ai pas de template de projet type. J’ai beaucoup lorgné depuis des années du côté de cookiecutter, je n’arrive pas à me motiver à l’utiliser sérieusement.
Enfin, j’installe toujours jupyter pour tester vite fait mon code, bien que j’utilise plus la console que le notebook. Et sphinx pour la doc.
J’ai parfois des clients qui exigent flask, et donc je fais du flask. C’est toujours à regret.
Il n’a rien que flask me permette que je ne puisse faire avec Django, mais il y a une tonne de trucs à réimplementer à la main à chaque fois. À documenter. À tester. Tout ça pour changer de projet flask, et tomber sur un nouveau loustic qui a fait les trucs à sa sauce et tout recommencer.
Les projets flask ne sont bien faits que par ceux qui savent déjà très bien mener un projet Web, ce qui n’est pas la majorité des gens qui l’utilisent: en effet, il attire les utilisateurs par la simplificité de son API, et leur donne l’illusion d’être à la hauteur.
flask reste un excellent produit pour l’éducation, ou pour un petit projet vite fait, ce pour quoi je le choisis avec plaisir. Mais la majorité des projets flasks sur lesquels j’ai travaillé n’ont guère le niveau de qualité qu’on rencontre en moyenne dans les projets Python. C’est qu’on s’habitue, à force.
J’essaye aussi d’aimer SQLALchemy, dont je reconnais la flexibilité et la puissance. Mais son ergonomie est pénible, et la gestion des sessions suffisamment tortueuse pour se tirer une balle dans le pied si on cligne trop des yeux. Si j’ai des problèmes de perfs, je fais du SQL à la main de toute façon et j’utilise du cache en masse. Je reste donc sur SQLA seulement si flask, ou hors Web. Et encore, des fois je peeweese.
L’ORM de Django est une aberration en bien des points, sauf un seul. Il est éminemment pratique. Et je sais jusqu’où je peux le pousser: loin, très loin. Max va se gausser en lisant ces lignes, mais je me lasse de la beauté du code et de la pureté (ta gueule mec, arrête sourire, je te vois).
Bref, Django pour les seniors. Django pour les juniors, même si ça prendra plus de temps que flask, mais au moins le framework leur évitera de faire de la merde comme au temps de PHP à la main.
Non, je n’utilise pas les trucs du genre sanic, growler, vibora, quart, etc. Si ils sont toujours activement développés dans 3 ans, on en reparle.
Bonne nouvelle ceci dit, la doc d’asyncio est enfin potable, si vous voulez vous y mettre. Mais ça mérite quand même un article.
Ceci dit, les occasions de faire de l’asyncio sont rares. REST reste (hu hu) quand même l’option reine, HTTP2 peut se déployer via proxy et les threads assurent le plus souvent des perfs suffisantes. Pour être parfaitement honnête, j’utilise plus asyncio pour des scripts, daemon, et autres tâches de fond :)
En parlant de tâche de fond, je reste sur du celery, surtout depuis que je sais qu’on peut l’utiliser avec presque zero config. C’est le moins pire des systèmes. De toute façon j’ai presque toujours un redis sous la main, c’est bien trop facile et pratique pour s’en passer.
J’ai pas encore mis en prod django channels, ou aWSGI, mais je ne suis pas du tout convaincu par ces solutions, donc j’attends de voir.
J’ai eu l’occasion d’utiliser crossbar un peu plus. L’outils est toujours excellent, mais l’API a changé sans pour autant s’améliorer. Ils se recroquevillent dans l’illusion qu’un produit spécialisé dans l’IoT est une bonne stratégie, mais c’est une voie de garage à mes yeux. Le vrai potentiel est dans le Web. Je me fais à l’idée que le projet n’attendra jamais son potentiel tant que personne n’écrit une surcouche, et que ce ne sera pas tavendo qui le fera.
Libs
Les libs changent constamment, partant et venant selon la nécessité des projets. Au mieux puis-je vous dire ce que j’irais chercher si j’avais cette problématique.
cli: click. Ça me fait mal de le dire, car je suis pas fan du style des APIs d’Armin (l’objet request global de flask, sérieux…), mais quand il fait un truc, on est sûr que ça marche. J’ai eu trop de limitations avec les alternatives.
Calculs numériques: numpy. À mon niveau je n’ai jamais besoin de scipy ou pandas.
Pour le parsing de conf je fais de plus en plus de toml, mais j’ai pytoml est pas terrible. Je vous ferai un retour sur contoml qui, si tout se passe bien, devrait être mon futur default.
J’ai beau essayer très fort de ne pas répondre en ligne, des fois je craque. Mais je me soigne, globalement j’ai récupéré plein de temps, et ça se voit sur mon quotidien.
Et ce craquage, et bien il est cette fois dû à une totale mécompréhension des types de texte en Python 3.
Mais c’est bien normal: Python 3 ne gère pas le texte de la même manière que la grande majorité des langages de programmation, justement à cause de la débâcle qu’on a eue en Python 2. Du coup, de nombreux programmeurs arrivent avec leur expérience d’ailleurs, et tentent de l’appliquer tel un utilisateur de SVN migrant sur git. En surface ça semble coller, malheuseuement à l’usage, ça fait faire des erreurs.
Donc un peu d’explications.
En informatique, tout est une histoire de convention. On dit que tel mot clé a tel effet. Que tel nom suppose telle chose. Que tel code de retour implique telle erreur. Que tel schéma XML représente tel type de document.
Essentiellement, tout cela est arbitraire: des gens ont décidé qu’il en serait ainsi. Impossible de deviner que ce que fait yield ou with si vous n’avez pas d’expérience similaire avant. Impossible de savoir que le code 0 en bash ou 200 en HTTP signifie tout va bien sans qu’on vous transmette l’information, ou faire de nombreux tests.
Quand je dis arbitrairement, évidemment je ne veux pas dire complètement sans raison. Il y a des raisons techniques, politiques, économiques, et parfois esthétiques à ces conventions. Cela n’en retire en rien l’aspect parfaitement artificiel de ces choix.
La convention la plus omniprésente, et pourtant aujourd’hui la plus masquée dans un monde où on utilise massivement des langages de haut niveau comme Javascript, Ruby, PHP et Python, est celle de l’organisation des octets.
Musique !
…je vois même plus le code : tout ce que je vois, c’est des blondes, des brunes, des rousses.
Tout ce qui passe par nos ordinateurs n’est qu’une suite de zéros et de uns, que nous avons groupés par paquets de 8:
Seulement la grande révélation, le “aaaaaaahhhhh okayyyyyyy” qui arrive un jour dans toute vie de dev, c’est que ces paquets de 8 ne veulent rien dire. Rien. C’est nous qui avons décidé, arbitrairement encore une fois, de leur signification.
Vous voyez ce moment dans les films et séries où un personnage arrive à “lire du binaire” ?
Evidement, “c’est une representation binaire ASCII de coordonnées WGS 84 Web Mercator” est plus dur à caser dans un dialogue
Le binaire n’est pas un langage, pas plus que les lettres “abcdefghijklmnopqrstuvwxyz”. Vous pouvez utiliser ces lettres pour représenter certains mots italiens, français, anglais, un nom propre (sans langue), le label d’un immeuble (sans langue encore) ou un chiffre latin.
Que veut dire “les gosses” ? Pour la même combinaisons de lettres, cela signifie “les enfants” avec la convention française européenne, et “les couilles” avec la convention québéquoise.
Pour le binaire c’est pareil, ce que veut dire un octet dépend de la convention que vous avez choisie.
Je peux lui appliquer la convention ASCII, et donc supposer que c’est un texte dans un certain format. Voici ce que ça donne en Python:
>>> data = bytearray([0b1100001, 0b1100010, 0b1100011, 0b1100100])
>>> print(data.decode('ascii'))
abcd
Les processeurs modernes ne comprenent pas nativement l’american apparel
Ou je peux lui appliquer une autre convention, et decider de lire ces octets comme si ils étaient le dump d’une structure C. Interprettons en Python ces octets comme un entier non signé en big-endian:
Même suite de bits, mais selon la convention choisie, elle veut dire les lettres “abcd” ou le nombre “1633837924”. Et oui, comme il n’y a pas une infinité de combinaisons de 0 et de 1 qui tiennent dans un espace mémoire limité, différentes conventions vont utiliser les mêmes octets mais décider que ça veut dire quelque chose de différent.
En fait, même des conventions pour le même type usage ne veulent pas forcément dire la même chose. Par exemple, prenez l’octet:
11101001
Un octet somme toute sympathique, de bonne famille. Il ne paie pas de mine, mais c’est un membre utile de la société.
Et maintenant, quelqu’un vous donne un indice, il vous dit que cet octet représente… du texte.
Super !
Oui, mais du texte avec quelle convention ? Car les pays du monde entier ont créé leur propre convention pour représenter du texte.
Avec la convention “cp850”, utilisé par la console DOS ?
>>> bytearray([0b11101001]).decode('cp850')
'Ú'
Vous voulez rire ? Le premier à remplacé presque partout le second parce qu’ils contiennent les mêmes lettres. Elles ne sont juste pas représentées par la même combinaison d’octets.
Et cet octet, que veut-il dire avec la convention “utf8”, qui est aujourd’hui le standard international recommandé pour représenter du texte ?
>>> bytearray([0b11101001]).decode('utf8')
Traceback (most recent call last):
File "", line 1, in
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe9 in position 0: unexpected end of data
Il n’a pas de correspondance. Cet octet n’est pas de l’utf8 valide.
Si vous voulez représenter ces lettres en utf8, il faut utiliser une convention différente, en utilisant non pas un seul octet, mais une séquence d’octets:
Vous pourriez croire que puisque le texte est particulièrement compliqué, c’est normal d’avoir des conventions qui divergent. Mais non, c’est juste la nature des conventions. Puisqu’elles sont arbitraires, l’une n’est pas plus “la vérité” qu’une autre. On retrouve la même chose avec les nombres:
La même suite d’octets peut représenter deux nombres totalement différents, selon que je décide de les lire comme des “short”, ou des “unsigned short”.
Et l’inverse est aussi vrai.
Ben oui, si quelque chose peut être interprété de plusieurs façons, on a aussi le fait que deux représentations différentes peuvent être interprétées … pour aboutir au même résultat.
Par exemple, le nombre des doigts de ma main peut être représenté de plein de façons différentes:
décimal: 5
français écrit: cinq
chiffre latin: V
anglais écrit: five
espagnol écrit: cinco
base deux: 101
structure C d’un signed short en little-endian avec Python: bytearray([0b101, 0b0])
Que de manières différentes, pour le même concept ! En plus, il y a confusion possible: V est une lettre également. cinq, five et cinco utilisent le même alphabet, mais pas les mêmes symboles spécifiques, pour représenter la même chose. Et le plus confusionant, 101 est une représentation binaire, mais bytearray([0b101, 0b0]) aussi.
Bref, voilà toute la complexité de la différence entre la donnée, un concept abstrait qui n’existe pas, et sa représentation, une convention humaine concrète qui nous permet de communiquer entre nous.
Donc, pour lire “du binaire”, ou faire n’importe quoi en informatique, il faut connaitre la convention utilisée. Mais pas juste en informatique: pour lire le journal, il faut connaitre la convention des symboles imprimés sur les pages, pour conduire sans se faire tuer, il faut connaitre la convention des panneaux, et pour parler, il faut connaitre la convention de la compression des molécules d’air émise par l’appareil buccal et respiratoire d’un individu qui vient rencontrer votre système auditif.
Vous êtes un être très conventionnel au fond.
Évidemment on trouve la même chose en Python. Par exemple vous pouvez utiliser plusieurs conventions pour demander à Python de créer le même nombre en mémoire:
Inversement, "1" et 1 paraissent similaire, mais ils ont différents buts. Le premier est un outil destiné à l’affichage, qui matérialise le caractère représentant le chiffre arabe après le zéro. Il est stocké en interne avec une séquence d’octets similaire à:
>>> bin(ord("1"))
'0b110001'
Tandis que que le second est un outil fait pour faire des calculs avec la plus petite valeur positive entière non nulle. Il est stocké en interne avec une séquence d’octets similaire à:
Je simplifie bien entendu, en vérité la representation interne des nombres et du texte en Python est plus complexe que cela, et dépend de l’implémentation choisie, du type de processeur, de la taille de la donnée et de votre configuration.
Retour sur le type bytes
J’ai soigneusement évité d’utiliser le type bytes durant cette démonstration, le remplaçant techniquement inutilement (mais pédagogiquement brillamment, car je suis génial) par bytearray.
En effet, toute cette leçon est là pour arriver à la conclusion que bytes ne représente pas du texte, mais si je vous avais montré tout ça avec lui, voilà qui vous aurait interloqué:
“Heu, mais c’est du texte !” me dirait alors un lecteur ayant diagonalisé l’article.
Mais bien entendu que non.
bytes ne présente pas du texte, c’est une structure de données dont le but est de permettre de manipuler une séquence d’octets ordonnée, et ce manuellement. N’importe laquelle.
Or, il se trouve que beaucoup de langages de programmation représentent le texte comme un array d’octets, et y attachent quelques opérations de manipulation. C’est le cas du C, ou de Python 2 par exemple. Les gens ayant eu cette expérience pensent donc que b'abcd' représente du texte, allant parfois jusqu’à aller lui donner l’appellation de “byte string”.
Il n’existe rien de tel en Python 3.
En Python 3, vous avez deux types pour manipuler des séquences d’octets: bytes et bytearray. Ils sont équivalents, à ceci près que bytes est non mutable (non modifiable) alors que bytearray est mutable (modifiable).
Ces types peuvent contenir n’importe quels octets, et nous avons vu ensemble qu’une même séquence d’octets pouvait être interprétée différemment selon la convention choisie pour la lire. Évidemment il est préférable de la lire avec la même convention qui a été utilisée pour la produire, sans quoi on ne comprendra pas ce que le producteur de la donnée à voulu dire.
Sauf que…
Beaucoup d’outils en informatique utilisent les conventions ASCII et hexadécimale pour symboliser les valeurs des octets. Si vous lancez Wireshark pour regarder les paquets d’un protocole réseau ou si vous ouvrez un PNG avec xxd, on va vous représenter le contenu avec un mélange de ces conventions.
Pour des raisons pratiques, Python fait donc la même chose, et permet ainsi de visualiser (ou produire) le type bytes à l’aide d’une notation ASCII:
Ou d’une notation héxa (ironiquement, l’héxa est representé par une combinaison de caractères ASCII \o/) si les valeurs ne tiennent pas dans la table ASCII:
Donc bytes, bien qu’il puisse contenir des octets interprétables comme du texte, n’est pas particulièrement fait pour manipuler du texte. Il peut contenir n’importe quoi. Mais pour des raisons pratiques, sa représentation dans le terminal est faite avec une convention familière. Après tout, il faut bien l’écrire en quelque chose pour l’affiquer à l’écran.
Si on veut manipuler du texte en Python 3, il faut utiliser le type str, qui est l’outil spécialisé dans la representation et la manipulation textuelle. Si vous savez qu’un type bytes contient des octets qui representent du texte, alors utilisez la méthode décode() avec la bonne convention (appelée “charset”), pour récupérer un str:
>>> print(b'P\xc3\xa8re No\xc3\xabl'.decode('utf8'))
Père Noël
Toute cela n’était bien entendu pas vrai en Python 2. En Python 2, le type str était un array d’octets, rendant tout cela bien confus, et amenant à plein d’erreurs. L’introduction lors de la version 2.0 de l’objet unicode pour pallier le problème, bien que très utile, n’a fait que rajouter à l’incomprehension des nouveaux venus.
Or le monde extérieur, lui, n’a pas d’abstraction pour le texte. Faire des abstractions, c’est le rôle du langage de programmation. Si vous écrivez dans un terminal, ou lisez depuis un terminal, un nom de fichier, le contenu d’une base de données, une requête AJAX, etc., ce sont évidemment des octets qui sont échangés, et il vous faut la bonne convention pour faire partie de la discussion.
Le type bas niveau bytes est un outil qui sert donc à communiquer avec le monde extérieur, tandis que les types haut niveau (str, int, list, etc.) sont des outils qui font l’abstraction de ces conventions, pour vous permettre de manipuler confortablement un concept général (du texte, un nombre, une collection ordonnée) à l’interieur des murs de votre programme.
Je mets une fortune dans mes casques, que j’abime et perds en plus très souvent. Or, j’ai toujours eu une relation mitigée avec les écouteurs Bluetooth (et le BT en général d’ailleurs…), et je suis assez froissé par la tendance à supprimer les jacks.
Le fil d’un ami m’a fait pourtant tester les airpods, et j’ai été surpris par la qualité du son et la facilité d’usage. J’ai cherché un concurrent.
Après enquête, j’ai tenté les Jabra Elite 65T. Après des mois d’usage, voici ce que je peux en dire…
Les plus:
Le son est excellent, particulièrement pour la taille sur du sans-fil, y compris sur du
classique, et les basses ne sont pas sur amplifiées comme c’est souvent le cas pour plaire à la masse;
C’est confortable. Je les porte des heures;
5h d’autonomie + 5 de secours avec le boitier. Je suis arrivé au bout seulement 2 fois
malgré des mois d’usage, donc pas un problème. Mais c’est vrai que les airpods font le double.
La synchro Bluetooth est parfaite avec portable récent (donc le messie bt5): rapide,
sans galère. Quand on ressort les écouteurs du boitier, le pairing est automatique et transparent.
Le boitier de transport / chargeur / batterie de secours fonctionne à merveille.
L’attache dans l’oreille est excellente. On peut se faire secouer, courir, faire du
yoga… Ça bouge pas.
On peut écouter avec une seule oreille, mais seulement la droite.
Les appels sont limpides, on a du mal à croire que ce petit micro marche si bien.
Après la perte inéluctable des deux écouteurs, j’ai fait une demande au SAV. 40 Euros,
et reçu en 2 jours. Beau. Resyncro instantanée une fois placée dans le boitier.
De vrais boutons qui permettent de contrôler pleinement la lecture, et pas juste 3
tapotements limités et difficiles en mouvement.
3 tailles embout. Et choisir les bons a un gros impact sur le confort. Les
intra-auriculaires à taille unique, ça m’a toujours laissé perplexe.
Bonne isolation du son extérieur.
Retirer un écouteur coupe la musique.
Zéro latence. J’ai eu des écouteurs BT moins cher, et regarder des films avec était un
enfer. Là c’est fantastique, avec VLC ou Netflix dans le train, on se fait plaisir.
Les moins:
180 euros à l’achat. Bam.
Le boitier est trop gros. Contrairement à celui des airpords, le mettre dans la poche n’est
pas aussi discret qu’une boite d’allumettes.
Il y a un mode pass-through si vous êtes en vélo et que l’isolation sonore est dangereuse,
mais il est pas ouf. Mieux vaut reste sur une écoute d’une oreille.
Certains comportements sont contre-intuitifs: retirer l’écouteur gauche coupe la musique,
mais en fait on peut la relancer sur un seul écouteur en pressant le bouton principal. On peut aussi désactiver ce comportement via une app pour partager le son avec son voisin. Parfois l’écouteur gauche se met en veille quand il reste trop longtemps éloigné du droit, alors alors il faut une pression longue dessus pour le réveiller: le web est plein de gens qui croient que leur écouteur ne marche plus. Rien n’indique ces manipes sans un bon vieux RTFM.
Finalement, ces petits joujoux m’ont réconcilié avec le sans-fil, et je n’ai presque plus touché à mes écouteurs ou mes baffles Bose. Certes, je n’écoute pas du flac, donc même si la qualité est bonne pour du mp3, j’imagine qu’un audiophile confirmé y trouvera à redire.
Ok, ok. Dans ces conditions, virez le jack… quand l’USB-C sera supporté partout.
