PROJET AUTOBLOG


Sam & Max: Python, Django, Git et du cul

Site original : Sam & Max: Python, Django, Git et du cul

⇐ retour index

Lancer correctement python et ses commandes cousines

samedi 8 juin 2019 à 20:00

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

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:

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.)

Mais c’est trop chiant !

Absolulement, c’est aussi pour cela qu’on utilise des environnements virtuels.

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.

Stack Python en 2019 1

dimanche 3 février 2019 à 16:10

Suite au très bon billet Débuter avec Python en 2019, je me suis dit qu’il serait bon d’en rajouter une couche.

Après toutes ces années, qu’est-ce que j’utilise pour mes projets Python ?

D’abord, Python 3.6, partout

Pas la 3.5. Pas la 3.7.

La raison est que la 3.6 est un millésime exceptionnel, dans laquelle culminent des années de fixes et goodies. Malgré celà, sortie fin 2016, elle est facile à installer: ça prend quelques minutes sur même une centos 7 via les EPEL, ou sur une ubuntu 16.04 en utilisant le ppa deadsnake.

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.

Frameworks Web

Django (souvent avec django-rest-framework).

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.

Question async, j’utilise aiohttp mais aussi fais du asyncio à là main, en faisant bien attention aux goto.

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.

Dates: pendulum.

Validation de données: marshmallow.

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.

Gestion du pognon: money.

Lib graphique: wxPython. Je fais du QT sur demande client, mais c’est trop gros pour des projets de moyenne taille.

Encoding: toujours chardet et unidecode.

Manipulation d’images: pillow.

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.

Pour convertir du code Python 2 vers Python 3, python future et backport.

Pour faire du templating, jinja2.

Pour l’internationalisation, babel.

Hors de Python

Git. Vue. Webpack. Ubuntu.

J’évite docker comma la peste, même si certains clients le veulent à tout prix. Je fais du react, généralement sous la torture.

Pas grand-chose à dire de plus.

Ah si, j’ai laissé tombé zsh et fish pour revenir à bash. Le ROI me convient pas.

Le type bytes n’est pas du texte

vendredi 11 janvier 2019 à 12:30

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

Evidement, “c’est une representation binaire ASCII de coordonnées WGS 84 Web Mercator” est plus dur à caser dans un dialogue

C’est de l’enculage de dauphin.

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.

Par exemple, que signifie cette suite d’octets ?

1100001 1100010 1100011 1100100

Bah rien. Mais on peut lui donner un sens en lui appliquant une convention.

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

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:

     
>>> data = bytearray([0b1100001, 0b1100010, 0b1100011, 0b1100100])     
>>> import struct     
>>> struct.unpack('>I', data)     
(1633837924,)

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 “latin-1”, utilisé par 0.7% de tous les sites Web du monde ?

 
>>> bytearray([0b11101001]).decode('latin-1') 
'é' 

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:

 
>>> list(map(bin, 'é'.encode('utf8')))
['0b11000011', '0b10101001']
>>> list(map(bin, 'Ú'.encode('utf8')))
['0b11000011', '0b10011010']

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:

>>> struct.unpack("h", bytearray([0b11101001, 0b11101001]))
(-5655,)
>>> struct.unpack("H", bytearray([0b11101001, 0b11101001])) 
(59881,)

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:

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:

>>> 245 # base 10
245
>>> 0xF5 # hexadecimal
245
>>> 0b11110101 # binaire
245
>>> 245 == 0xF5 == 0b11110101
True     
>>> type(245)     
     
>>> type(0xF5)     
     
>>> type(0b11110101)     
 

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 à:

>>> list(map(bin, struct.pack('l', 1)))
['0b1', '0b0', '0b0', '0b0', '0b0', '0b0', '0b0', '0b0']

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é:

     
>>> bytes([0b1100001, 0b1100010, 0b1100011, 0b1100100])     
b'abcd' 

“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:

    
>>> print(b'abcd'.decode('ascii'))     
abcd     
>>> struct.unpack('>I', b'abcd')     
(1633837924,)

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:

     
>>> "é".encode('utf8')  # hexa C3 A9   
b'\xc3\xa9'     
>>> struct.unpack('h', b'\xc3\xa9')    
(-22077,)

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 

On a un très bon article sur l’encoding en Python sur le blog, d’ailleurs.

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.

Ecouteurs bluetooth

jeudi 10 janvier 2019 à 11:31

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:

Les moins:

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.

Le don du mois: Libre Office

mardi 8 janvier 2019 à 09:54

Microsoft Office est un bon produit. Voilà, je l’ai dit. Je peux ne pas apprécier Microsoft en tant qu’entreprise, reprocher de nombreux défauts à ses bébés, mais être objectif sur certains points: Excel, malgré ses bugs, reste la meilleure expérience de tableur au monde, .Net est une technologie très propre, et VSCode est un superbe éditeur que j’ai par ailleurs adopté.

Seulement voilà, je n’ai nullement l’intention de soutenir des formats propriétaires, l’obsolescence programmée, et l’abus de position dominante. Au contraire, je préfère soutenir le logiciel libre, les standards ouverts et le partage.

Et c’est là que Libre Office entre en jeu.

Je l’utilise donc au quotidien, pour faire des rapports, des lettres, des calculs, etc. Bien que je sois très à l’aise avec ma machine, j’utilise des fonctions relativement peu avancées, et ce logiciel comble donc tous mes besoins.

Malheureusement, Libre Office souffre de gros problèmes d’ergonomie, et pire encore, de fiabilité. Sa stabilité est douteuse, et en plus de la frustration liée au plantage, il m’arrive de perdre du travail, chose qui me rend furieux.

Je comprendrais donc parfaitement que quelqu’un choisisse de ne PAS utiliser Libre Office, pour toutes ces raisons.

Personnellement, j’ai la politique inverse, et j’utilise Libre Office pour les soutenir, et je vais donc reporter les bugs et autres problèmes quand j’en ai le temps. J’ai peu de temps en ce moment, donc je choisis de contribuer par don, ce qui j’espère aidera les auteurs à dépasser ces hics. Un jour peut-être.

Un peu comme Firefox que j’ai gardé pendant des années alors qu’il était inférieur à Chrome, jusqu’à ce que, soudain, il redevienne non seulement aussi rapide, mais rajoute des fonctionalités inédites comme les tab containers que n’a pas la concurrence.

Et voici donc un don de 50 euros pour cet excellent projet, qui derrière ces soucis, permet quand même à peu de frais de faire des choses absolument incroyables, le tout dans le respect de la communauté humaine.

Bien entendu, je vous invite à faire de même.