Vlákno názorů k článku Lupa: propojení programovacích jazyků Lua a Python od MilanV - Hodně zajímavé, co se dnes dá udělat. Ale...

Hodně zajímavé, co se dnes dá udělat. Ale pořád přemýšlím nad využitím. Samozřejmě pokud napíšu např. v pythonu GUI aplikaci, ve které budu chtít dát uživateli možnost si část konfigurace naskriptovat, tak je to možná zajímavá varianta.

Ale pokud by mělo jít jen o bezpečnostní prvek diky oddělení od zbytku python kódu, tak navrhuju revoluční řešení: projekt pypy: python v pythonu. Oddělené prostředí, tj. sandboxing, a zároveň snadný převod typů mezi hostitelským a hostovaným prostředím!

Podle známého citátu z vodní hladiny:

||| : "Co teď budeme dělat?"
Ξ : "Překladatele."
||| : "A co jazyky?"
Ξ : "Nejsou potřeba. U nás se mluví stejně jako u vás. Ale psst! Lidi na to ještě nepřišli!"

P.S.: Bylo mi divné, že bych byl s takovým nápadem sám. Chvíli mi trvalo než jsem něco našel a není to plnohodnotný python, ale možná to byl záměr kvůli bezpečnosti:

https://pypi.org/project/sandboxed-python/

Škoda, že to Python nepodporuje přímo, založit sandboxované podprostředí...

11. 8. 2026, 10:19 editováno autorem komentáře

jj to vypadá jako hodně podobné řešení.

Popravdě mě překvapilo, když se jeden člověk na Lua konfeře přihlásil, že Luu embedují (to je slovo...) do Pythonu, ale ono to smysl má. Jak kvůli bezpečnosti, tak i proto, že Lua skutečně JE lightweight (ne že to říká, ale na rozdíl od Pythonu skutečně je). To může hrát svoji roli, třeba u backendu ke kterému se připojují stovky uživatelů. Já to možná v článku nezdůraznil, ale kromě klasického interpretru Luy tam jde zvolit LuaJIT, který se co do rychlosti dá srovnat s překládanými jazyky.

Přemýšlel jsem o tom a asi v té dokonalosti oddělení do sandboxu je ten hlavní fígl. Jak také psal @MarSik (díky za odkazy!) ono to pak vede k tomu, že rychlejší sandbox pythonu v pythonu pak neprováděl plnou inicilaizaci, ale vždy nějakým způsobem používal hostitelský python. A navíc plný python je plný - tj. umožňuje operace jako natažení stovek knihoven, spouštění dalších procesů na systému, posílání signálů... Pak to není sandbox, ale "snadbox" - omylem se mi povedl překlep, který to ale, myslím, vystihuje...

Kompletně oddělené prostředí tím, že se pustí vlastní interpretr, a navíc umějící jen přesně definovanou množinu bezpečných operací (žádné volání system() apod. ) je vlastně dobrý nápad. Akorát vypadá divně, že pak máte projekt ve dvou jazycích. Ale to se po prvním překvapení asi dá zvládnout...

Je ten JIT vobec uzitocny, ak ide o embedded jazyk kde sa spusta nejaky kusok kodu? Myslel som si, ze to je pouzite hlavne ked sa nejaka iteracia opakuje velakrat. Vedel by som si to predstavit v programe ako GIMP, i ked tam sa ta narocnost asi offloaduje na GEGL alebo iny nativny kod.

Co si z dávných dob pamatuju, tak Python sandbox existoval. Jenže existovalo i milion a pět způsobů, jak z něj utéct, a tak se od toho na dlouho upustilo.

Příklady jako https://blog.delroth.net/2013/03/escaping-a-python-sandbox-ndh-2013-quals-writeup/ nebo https://nedbatchelder.com/blog/201206/eval_really_is_dangerous to ukazovaly názorně.

PyPy to trošku změnilo tím, že umí vygenerovat omezený interpret a možná se za poslední dekádu zlepšily ty izolační techniky, ale už to moc nesleduju.

U nás využíváme Lua jako embebed scriptovací jazyk pro univerzální Reporter (C#). Definice reportů (v Lua) jsou uloženy v datové tabulce, máme k tomu i vývojový nástroj s jednoduchým debugerem. Na výstupu je buď tabulka nebo graf, obé exportovatelné v mnoha formátech. Navrch je tam nějaká interakce s uživatelem. Řekl bych, že za těch 25 let, co je to v produkci, jsme to celkem vyleštili a už se do toho dlooouho nesáhlo, jen se přidávají další a další reporty.