#przenosnosc — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #przenosnosc, aggregated by home.social.
-
Wbrew wszelkiemu prawdopodobieństwu, 32-bitowe #time_t bywa pomocne.
I tak na przykład wczoraj znalazłem ciekawy błąd w bibliotece #Moto. Biblioteka przekazywała do botocore datę w formie zbliżonej do ISO-8601, ale bez separatorów, np. "20240907201715" — lecz botocore oczekiwało albo numerycznego znacznika czasu w stylu uniksowym, albo bardziej standardowego formatowania daty. Tak więc te połączone cyfry były błędnie interpretowane jako uniksowy znacznik czasu, co dawało rok 643378.
Podejrzewam, że gdyby nie to, że 32-bitowe time_t sypie się na tak wielkich znacznikach, to pewnie jeszcze długi czas nikt nie zauważyłby, że daty są błędnie interpretowane.
-
Kolejny ciekawy problem z dziedziny przenośności: kodowania #UTF-16, UTF-32, UCS-2 i UCS-4 są zależne od kolejności bajtów. Oznacza to, że można je zakodować albo jako big endian, albo jako little endian. Kodując ciągi znaków, #Python używa kolejności bajtów systemu i dopisuje Byte Order Marker na początku pliku. Przy dekodowaniu, automatycznie odczytuje zapisany wcześniej BOM, by określić właściwą kolejność bajtów, dzięki czemu wszystko "po prostu działa".
Problemy zaczynają się, kiedy próbujemy porównać zakodowane dane na poziomie bajtów, np. porównując zapisany wcześniej jako UTF-16 plik z wynikiem wywołania `encode()`. Jeżeli plik był zapisany na systemie little endian (jak to zwykle bywa), a testy uruchamiane są na systemie big endian, nagle okaże się, że dostajemy dwa różne ciągi bajtów!
"Oczywistym" rozwiązaniem jest wymuszenie konkretnej kolejności bajtów, np. użyjąc kodowania `utf-16-le` zamiast `utf-16`. Tu jednak pojawia się kolejny problem — kiedy podajemy określoną kolejność bajtów, Python nie zapisuje już BOM — tak więc porównanie na poziomie bajtów wykaże różnicę w postaci brakującego BOM. Można to jednak rozwiązać prostą sztuczką — dopisując BOM (`\ufeff`) na początku kodowanego ciągu.
https://github.com/python/importlib_resources/pull/313/files