Názory k článku Propojení Pythonu s nativními knihovnami s využitím balíčku ctypes

Mne celkem trvalo nez jsem prisel na to, jak spravne resit, kdyz potrebuju alokovat pamet spravovanou pythonem, ale jeji velikost urci az C kod. Nakonec jsem zjistil, ze se dokonce pres ctypes da predat alokator jako funkce, takze C API bere na vstupu misto bufferu alokator a vola si ho podle potreby. Ten alokator pri vykonavani zase prepne zpatky do Pythonu, vytvori normalni managed buffer pozadovane velikosti, a vrati ho do C.

Neni to hezke, ale rekl bych, ze je to asi spravny postup, protoze to pak na strane Pythonu uz nevyzaduje zadne specialni chovani se k tem bufferum.

Viděl jsem v článku zmínku o Zig(u). Že by se blížil nějaký článek?

To je otázka na mě? :-)

Ak nie tak ja sa pripajam za Zig. Trochu som to skusal ale stale chystaju nejake velke zmeny a chybaju nejake prakticke rady ako v tom nieco naprogramovat. Od pouzitia 3rd party kniznic (mimo Zig) az povedzme po nejake GUI.

bude, ale asi az v Q2 (ty korporace me tedy ovlivnuji hodne, uz taky planuju v kvartalech :/)

Měla být :D ADHD.
Mne Zig láká daleko více než Rust. Pak ještě srovnatelně snad Jai, ale Zig mi přijde více reálný na projekt.

28. 2. 2024, 18:16 editováno autorem komentáře

To zni rozumne, Samozrejme ale v cecku si nenechavas pointer na ten buffer, protoze se nevi, kdy ho Python uvolni, ze?

Jasne, Ccko je jednorazova funkce, ktera ma ten buffer naplnit a pak uz ho nepotrebuje.

jo jasne. ted me ani nenapada, kdy to muze "haprovat" :-) ale myslenka volani mallocu s automatickym GC (pres Python VM) je asi dobra

maximálně ve chvíli, kdy je nutné naprogramovat obdobu `strcat` nebo tak něco. Tomu bych se vyhýbal pokud to jde (a kupodivu to většinou jde).

Ano, ono to u větších projektů je asi nejlepší řešení, pokud člověk nechce pořád řešit memory leaky na jedné straně a NPE na straně druhé :-)