Názory k článku Manipulace s binárními datovými strukturami v Pythonu

Diky, moc hezky priklad s tim PNG.

Ta kombinace stuct, bytes a zlib je pěkná. Má to reálné využití třeba oproti PIL nebo PurePNG? Hmm a napadá mě, že GIF by takto elegantně asi udělat nešel, protože tam zlib bude mít jiné parametry.

No PIL má jeden problém - spoustu závislostí na systémových knihovnách.

Ty jsou vypsány například tady https://pillow.readthedocs.io/en/stable/installation/building-from-source.html. Ano píše se, že optional, ale instalace PIL/Pillow si s sebou ty knihovny vezme - takže si nataháte spoustu potenciálních vektorů útoků (asi nejvíc toho bylo hlášeno pro libtiff, ale obecně zrovna tyto knihovny se updatují docela hodně).

PurePNG je skutečně Python-only realizace, takže v tomto ohledu je to méně starostí. A to řešení v článku si myslím, že pro běžné účely může klidně stačit (jak říká Rob Pike "A little copying is better than a little dependency" - nebrat doslova, ale zase na druhou stranu druhý extrém je taky "zajímavý" - https://github.com/i-voted-for-trump/is-even apod.)

Díky. Opět skvělý článek.

Dívám se, že i knihovna zlib je docela "živá", čekal bych, že to, za ta léta už bude vyladěnější. Na mém Python 3.10.12 to wbits nedalo, ale i bez toho to šlo dobře.

zlib.compress(data, /, level=-1, wbits=MAX_WBITS)

Changed in version 3.6: level can now be used as a keyword parameter.

Changed in version 3.11: The wbits parameter is now available to set window bits and compression type.

Díky!

Ono to nastavení wbits jsem tam asi ani dávat nemusel, protože 15bitů je výchozí hodnota, která je čistě náhodou kompatibilní s PNGčkem.

(jinak zcela na okraj: 3.10/3.11 jsou pomalejší, než 3.12, tady se přechod asi vyplatí. Navíc je 3.12 v režimu vydávání bugfixů - https://devguide.python.org/versions/)

Tak to raději nebudu zmiňovat, že mám pár produkčních věcí ještě i na Pythonu 2.5 a 2.7.

V některých případech může být méně více.

Můj poslední úlovek je https://pocketpy.dev/
Takhle ochočený "Python" má 400k (200K by se mi tedy hodilo víc).

Ale jo, věřím, že 2.7 se ještě bude objevovat (ostatně my tady oprašujeme Javu 1.4 a to se už nezmění, ty systémy ne a ne umřít :-).

Díky za odkaz, ten PocketPy vypadá zajímavě. Já sice pro tyto účely raději Luu, ale třeba kdyby někdo plně konvertoval MicroPython pro hlavní platformy (včetně toho jejich assembleru), tak bych se vůbec nezlobil.

A nestačila by Lupa? https://pypi.org/project/lupa/

Co se MicroPythonu týče, ten se dá slušně portovat na kde co. Kromě všemožných mikrokontrolérů, může běhat i nad Lin/Mac/Win. https://github.com/micropython/micropython/tree/master/ports Takže na "hlavních" platformách vlastně je, byť ta vyladěnost je místy nevyzpytatelná.

Ale pokud ta platforma není nějak HW omezená, nebo to není třeba pouštět ve stovkách nezávislých procesů, tak vyhrává klasický CPython.

MicroPython používám například na EV3 https://en.wikipedia.org/wiki/Lego_Mindstorms_EV3 s Linuxovou distribucí EV3DEV https://www.ev3dev.org/

Na té kostce startuje cca 3x rychleji než CPython.

S využitím znaků b, h, i, l, q lze volit počet bajtů pro uložení celočíselné hodnoty. Postupně se jedná o 8, 16, 32, 64 a 128 bitů.

... mi nepřijde zcela validní. Na 64-bitovém pythonu nativně 128-bit integer asi nedostaneme. Nakonec i ve výstupu demonstračního skriptu více než 8 bajtů není.

Rovněž by bylo dobré zmínit, že pokud není specifikovaná indianita/nativita tak platí že je použito nativního uspořádání bajtů, velikosti typů a zarovnání v "céčkovské" struktuře (proto taky ten název modulu struct). V takovém případě se může použít (ale nemusí) speciální znak "@". Pozor, ten má však jiný význam než v příkladech používaný "=". Při použití druhého zmiňovaného se nepoužije nativní velikosti nýbrž tzv. standardní což se ale obecně uplatňuje pro všechny případy krom "@" (viz. https://docs.python.org/3/library/struct.html#struct-alignment a https://docs.python.org/3/library/struct.html#format-characters), tedy i pro "<", ">" nebo "!". Rozdíl v chování pak lze jednoduše ověřit např.

>>> print(struct.pack("@l", 42).hex(" ", 1))
2a 00 00 00 00 00 00 00
>>> print(struct.pack("l", 42).hex(" ", 1)) # To samé jako s použitím "@"
2a 00 00 00 00 00 00 00
>>> print(struct.pack("=l", 42).hex(" ", 1)) # Standardní velikost
2a 00 00 00 

Díky za doplnění. Zrovna k tomu @ jsem se chtěl ještě vrátit a ukázat využití, když se volá céčkový kód (a ne když se pracuje spíše s binárními soubory). Samozřejmě máš pravdu.

Ta šířka: jo tam je to složitější, protože na x86-64 bude "l" stejně široké jako "q", ale jinde to může být tak, že "i" bude stejně široké jako "l", ale "q" bude dvakrát tak širší. Hmm 128bitů pro "q" jsem ale taky vlastně neviděl, i když teoreticky to možné je.