Dotaz: sjednocení __builtins__ a globals v pythonu

[vencas]

Zdraívm,

mám program v c++ skriptovaný v pythonu. Dělá mi problémy, že každý interpreter pythonu má svoje vlastní globální proměnné, které nejsou mezi interpretery sdílené. (Sad globálních proměnných (tj. interpreterů) je několik: jednak samotný embedded python v c++, pak na konzoli běžící ipython a pak libovolný počet pythonských konzolí přes telnet). Chtěl jsem to vyřešit tak, že bych sdílené proměnné vytvářel ve jmenném prostoru __builtins__; má to ale háček:

$$$ __builtins__.a=5
$$$ a # vypíše __builtins__.a
5
$$$ a=4 # přiřadí ale do globals()['a'], v tomto případě navíc locals()==globals()
$$$ a # vypíše globals()['a']
4 

Výsledek tedy je takový, že proměnné je "jen pro čtení" v tom smyslu, že když se pokusím přiřadit hodnotu a neuvedu explicitně __builtins__, pak proměnnou zastíním globální proměnnou: v současném interpreteru tedy budu vidět tu novou hodnotu z globals() a v ostatních tu z __builtins__. Guláš. Když budu chtít vytvořit proměnnou, pak před ni musím napsat __builtins__.něco, taky nic moc.

Bohužel nevím, jak (pokud to vůbec jde) globals a __builtins__ sjednotit. Zkoušel jsem triky jako

globals=lambda: __builtins__.__dict__

, ale bez úspěchu (globals() se zjevně interně pro nalezení proměnné nepoužívají. (Pochopitelně některé proměnné musejí být pro interpreter lokální, aby se mezi sebou vůbec rozlišily, ale těch bude nejspíš jen pár)

Máte nějako nějaký nápad? Díky za něj.

Odpovědi

[JS]

No, je to oblast, v ktere se moc nevyznam, ale zkusim to:

1. Python AFAIK neumoznuje sam od sebe sdilet promenne mezi interprety, protoze to by znamenalo nejake zamykani a pokud by Python mel na promennych zamky, nebyl by potreba global-interpreter lock (GIL).

2. Nevim, __builtins__ asi neni ta spravna cesta, to je podle me spis jen alias na ty vestavene funkce, ktery je k dispozici i v pripade, ze si je predefinujete. Tim chci rict, ze za __builtins__ patrne zadny skutecny slovnik neni.

3. Co se tyce reseni, tak nevim. Premyslel jsem o moznosti implementovat nejak vlastni slovnik v C++, ktery by bylo dostupny vsem tem Pythonum pres zamky, ale to ma jeden velky hacek - Python ma vlastni spravu pameti, a tedy neni jasne, co se stane, pokud interpret A dostane pod kontrolu objekt na halde interpretu B - osobne si myslim, ze minimalne s GC to nebude fungovat. Pokud by bylo GC vypnute, fungovat by to mohlo, ale je to asi dost riskantni. Navic, musite zarucit, ze vsechny interprety bezi ve stejnem procesu.

4. Jeste by byla moznost pouzit nejake posilani zprav a pickle/unpickle. Mozna by to bylo nejjednodussi ve vasem pripade. Jak uz jsem naznacil, kvuli obtiznosti sdileni pameti vice interprety, kopirovani objektu se patrne neda vyhnout.

[MarSik]

Napadaji me dve moznosti (cecko nebo python, je to uplne jedno):

1) zvlast bezici proces a posilani zprav pres socket/pipe/neco - sem spada treba memcached, ktery se na to casto pouziva 2) sdilena pamet - nevim jak je na tom python, cecko urcite umi a python umoznuje v cecku napsane moduly (a je to slusne zdokumentovane), akorat je potreba davat bacha na zamykani

Oboji je to skaldiste dat a perzistentni objekty muzes zpristupnit treba pomoci jineho procesu, ktery je bude vlastnit a nejakeho xmlrpc..

Jinak __builtins__ je typove python modul.

[JS]

Jasne, ale vyse uvedene reseni uz je trochu slozitejsi v tom, ze uz nepujde primo o Python objekty, ale bude se to muset prevest. Takze ani tak to neresi kopirovani tech dat (budou se muset kopirovat do tech Python objektu, aby s nimi bylo mozne rozumne pracovat).

No jo, tenhle priklad krasne ukazuje nevyhodu systemu s vlastni spravou pameti.

[MarSik]

No zrovna ten rpc pristup by byly primo Python objekty, kde klienti by k nim meli pristup pres proxy objekt a byla by to porad ta sama instance.

Jinak sdilena pamet/memcached neni python objket.. jak jsem psal, je to jen skladiste.. a bylo by potreba kopirovat a zamykat.

Jinak vyrobit v ceckovem modulu objekt, ktery bude na sdilene pameti a bude spolecny pro vsechny neni problem. GC poresite proste tim, ze inkrementujete pocitadlo referenci.

[vencas]

Ono by bylo celkem jedno, jestli je objekt společný pro všechny nebo ne, protože všechny ty třídy jsou jen velmi tenké šlupky přes shared_ptr<c++-třída>(nějaký-objekt), takže ať jich je víc nebo ne, data mají stejná.

Šlo mi primárně o proměnné, aby je interpretery sdílely (resp. jejich jmenné prostory). Všechno to běží v jednom procesu, takže paměť sdílená je. Aby když napíšu a=, tak aby všude platilo a==5: v embed interpreteru (PyRun_SimpleString) i ve všech interaktivních interpreterech.

[vencas]

Oprava: aby když napíšu a=5, tak aby všude platilo a==5