Billet-Signet : Apprendre PyQt (en anglais)

Salut \o

On écrit Qt et pas QT. D’ailleurs, ça se prononce “cute” (/kjuːt/) et pas QT (/kjuːtiː/ ou /kyte/ en français).

Ah en effet ! Je ne savais pas pour la prononciation. Je corrige de ce pas. C’est corrigé !

RealPython est un super site pour apprendre pleins de truc comme la création d’un serveur HTTP, la programmation système, les bots Discord, etc. En gros pour tout ce que vous voulez faire en Python, il y a une forte chance qu’il existe un article associé sur RealPython.

Mmm le deuxième lien (qui concerne la manipulation de fichiers plutôt que la programmation système, mais bon Python est pas un langage système de toute façon) contient des conseils pas très à jour. L’ensemble du texte se concentre essentiellement sur os.path en mentionnant à peine pathlib. J’imagine que le tuto est un peu vieux parce qu’aujourd’hui, il n’y a aucune raison d’utiliser os et de se passer de pathlib. Aucun mot non plus sur l’interface PathLike qui permet d’intéragir avec la plupart des fonctions qui attendent un path. Le site a l’air de produire beaucoup de contenu mais pas nécessairement le maintenir à jour. Par ailleurs, le site me demande de s’inscrire pour continuer à le consulter… La flemme de configurer un filtre juste pour le bon cookie.

Mieux vaut passer par la doc ?

Pour pathlib spécifiquement, plutôt cette section de la doc qui regorge d’exemples.

Ce qui manque à pathlib je trouve, c’est os.walk. Après, c’est pas dur à recoder …

Cela me donne une petite idée de projet pour me faire la main : écrire un shell en Python et recoder des commandes UNIX « basiques » dans le style de cat foo.txt | grep bar. Une petite piste ici, même si l’article date.

Path.rglob("*"), qui en plus évite la création de listes temporaires et ne dépend pas du cwd (i.e. d’un état global…) comme os.walk.

cat et grep sont des programmes comme les autres, ils ne sont pas liés au shell (comme cd ou source le sont). Pas besoin de coder tout un shell si ce qui t’intéresse est réimplémenter cat et similaire.

Path.rglob("*"), qui en plus évite la création de listes temporaires et ne dépend pas du cwd (i.e. d’un état global…) comme os.walk.

Ça marche sur les systèmes non POSIX ?
C’est ce qui m’inquiétait le plus avec cette méthode.

Encore heureux oui, c’est un peu le but de pathlib d’être portable.

Tiens d’ailleurs en allant voir le code de glob par curiosité, je suis tombé sur cette PR qui ajoute Path.walk, probablement pour Python 3.12 comme 3.11 est en feature freeze depuis un moment maintenant. Malheureusement, ils ont implémenté la même API un peu pourrie qui oblige à aller chercher la doc pour connaitre l’ordre des éléments…

cat et grep sont des programmes comme les autres, ils ne sont pas liés au shell (comme cd ou source le sont). Pas besoin de coder tout un shell si ce qui t’intéresse est réimplémenter cat et similaire.

Je pensais à implémenter le piping aussi.

Attention à un petit détail. La commande ping classique utilise le protocole ICMP (donc pas UDP, ni TCP, ni même sur IP du tout puisqu’il est layer 3 lui-même). Les interfaces offertes par les langages de programmation et le système d’exploitation ne sont pas toujours bien fournies pour faire de l’ICMP, le besoin étant peu répandu. Il existe certainement des implémentations pour Python qui font tout le taf (qui savent appeler correctement le système ou forger elles-mêmes les paquets ICMP), mais attends-toi peut-être à avoir une expérience de développement moins fluide par rapport à ce qu’on fait avec des sockets UDP, TCP ou UNIX « classiques ».

Tu as besoin des droits root pour envoyer un paquet ICMP sous linux.

Scapy permet de faire un PING assez facilement.

Par-contre, ICMP utilise bien le protocole IP @sgble.

@sgble : piping comme dans a | b, pas la commande ping, je pense…

Je pensais à implémenter le piping aussi.

Honnêtement je ne pense pas que ça ait le moindre intérêt éducatif de coder un système de piping en Python parce que Python rend ça hyper trivial. Typiquement, le lien que tu as envoyé se prend massivement la tête pour gérer les pipes (et le peu que j’ai lu m’inciterait pas à lire le reste…). Au lieu de créer les pipes à la main, il suffit d’utiliser les abstractions déjà offertes par subprocess :

import subprocess

process1 = subprocess.run(cmd1, stdout=subprocess.PIPE)
subprocess.run(cmd2, stdin=process1.stdout)

Comme tu vois, ça casse pas des briques. D’ailleurs même dans des langages systèmes, faire des pipes va jamais bien plus loin que ça : tu crées un stream et tu branches les deux processus dessus pour lire et écrire. Même la libc a les abstractions qui vont bien (et ça ressemblerait comme deux gouttes d’eaux à ce que ton lien Python fait, je suspecte que l’auteur est un programmeur C qui connait mal Python et a bricolé un truc sans lire la doc d’abord).

Merci pour les précisions. C’était juste une idée de tout façon.

Ah mais oui, le piping ! mais où avais-je la tête ! Pas une seule seconde j’ai inféré autre chose que d’implémenter ping avec le contexte qui parlait de « recoder des commandes UNIX « basiques ».

Par-contre, ICMP utilise bien le protocole IP @sgble.

Oui, je me suis trompé, on fait bien de l’ICMP sur IP

J’ajouterais qu’il y a d’autres choses à prendre en compte dans la réalisation d’un shell (même minimal) en Python et qu’elles sont survolées voire ignorées dans l’article en question.

Par exemple la recherche de l’exécutable à lancer ne devrait pas être déléguée à subprocess.run mais être résolue en amont.

Aussi la gestion des builtins mériterait d’être plus avancée qu’un if par builtin (qui en plus les empêche d’être utilisées dans des expressions plus évoluées) et le parsing ne peut bien sûr pas se résumer à simple split sur la chaîne entrée.